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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document defines a generic Terminal/Integrated Circuit Card (ICC) interface. The present document is 
independent of the 3G USIM application and can thus be the platform for any IC card application. 

The aim of the present document is to ensure interoperability between an ICC and a terminal independently of the 
respective manufacturer, card issuer or operator. The present document does not define any aspects related to the 
administrative management phase of the ICC. Any internal technical realisation of either the ICC or the terminal is only 
specified where these are reflected over the interface. 

Application specific details for applications residing on an ICC are specified in the respective application specific 
documents. The Universal Subscriber Identity Module (USIM)-application for 3G telecommunication networks is 
specified in document 3G TS 31.102 [2]. 
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1 Scope 

The present document specifies the interface between the UICC and the Terminal for 3G telecom network operation. 
The present document specifies: 

the requirements for the physical characteristics of the UICC; 

the electrical interface between the UICC and the Terminal; 

the initial communication establishment and the transport protocols; 

the model which serves as a basis for the logical structure of the UICC; 

the communication commands and the procedures; 

the application independent files and protocols. 
The administrative procedures and initial card management are not part of the present document. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] 3G TS 23.038: "Alphabets and language-specific information". 
[2] 3G TS 31.102: "Characteristics of the USIM appHcation". 

[3] 3G TS 31.110: "Numbering system for telecommunication IC card applications". 

[4] 3G TS 31.111: "USIM Application Toolkit (USAT)". 

[5] ITU-T Recommendation E.l 18: "The international telecommunication charge card". 

[6] ISO 639 (1988): "Code for the representation of names of languages". 

[7] ISO/IEC 7810 (1995): "Identification cards - Physical characteristics". 

[8] ISO/IEC 7811-1 (1995): "Identification cards - Recording technique - Part 1: Embossing". 

[9] ISO/IEC 7811-3 (1995): "Identification cards - Recording technique - Part 3: Location of 

embossed characters on ID-1 cards". 

[10] ISO/IEC 7816-1 (1998): "Identification cards - Integrated circuit(s) cards with contacts. Part 1: 

Physical characteristics". 

[II] ISO/IEC 7816-2 (1999): "Identification cards - Integrated circuit(s) cards with contacts. Part 2: 
Dimensions and locations of the contacts". 

[12] ISO/IEC 7816-3 (1997): "Identification cards - Integrated circuit(s) cards with contacts. Part 3: 

Electronic signals and transmission protocols". 

[13] ISO/IEC 7816-4 (1995): "Identification cards - Integrated circuit(s) cards with contacts, Part 4: 

Interindustry commands for interchange". 
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[14] ISO/IEC 7816-5 (1994): "Identification cards - Integrated circuit(s) cards with contacts, Part 5: 

Numbering system and registration procedure for application identifiers". 

[15] ISO/IEC 7816-6 (1996): "Identification cards - Integrated circuit(s) cards with contacts, Part 6: 

Interindustry data elements". 

[16] ISO/IEC 7816-8 (1999): "Identification cards - Integrated circuit(s) cards with contacts, Part 8: 

Security related Interindustry commands". 

[17] ISO/IEC FCD 7816-9 (1999): "Identification cards - Integrated circuit(s) cards with contacts. 

Part 9: Additional Interindustry commands and security attributes". 

[18] ISO/IEC 10646-1 (1993): "Information technology - Universal Multiple-Octet Coded Character 

Set (UCS) - Part 1: Architecture and Basic MultiHngual Plane". 



3 Definitions, symbols, abbreviations and coding 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

3V technology Smart Card: smart Card operating at 3V-+ 10% and 5V + 10%. 

1.8V technology Smart Card: smart Card operating at 1.8V + 10% and 3V + 10%. 

3V technology Terminal: terminal operating the Smart Card - Terminal interface at 3V + 10% and 5V + 10%. 

1.8V technology Terminal: terminal operating the Smart Card - Terminal interface at 1.8V + 10% and 3V + 10%. 

Function: function contains a command and a response pair. 

Application DF: application DF is the entry point to an application. 

Access conditions: set of security attributes associated with a file. 

AppUcation: application consists of a set of security mechanisms, files, data and protocols (excluding transmission 
protocols). 

Application protocol: set of procedures required by the application. 

Card session: link between the card and the external world starting with the ATR and ending with a subsequent reset or 
a deactivation of the card. 

Current directory: latest MF or DFor ADF selected. 

Current EF: latest EF selected. 

Data Object: information coded as TLV objects, i.e. consisting of a Tag, a Length and a Value part. 

Dedicated File (DF): file containing access conditions and, optionally. Elementary Files (EFs) or other Dedicated Files 
(DFs). 

Directory: general term for MF, DF and ADF. 

Elementary File (EF): file containing access conditions and data and no other files. 

File: directory or an organised set of bytes or records in the UICC. 

File identifier: 2 bytes which address a file in the UICC. 

GSM session: that part of the card session dedicated to the GSM operation. 

ID-1 UICC: UICC having the format of an ID-1 card (see ISO/IEC 7816-1 [10]). 
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Master File (MF): unique mandatory file containing access conditions and optionally DFs and/or EFs. 

Multi-application card: card that can have more than one selectable application. 

Multi-session card: card that supports more than one concurrent selectable application session during a card session. 

Multi-application capability terminal: terminal that can support more than one application. 

Normal USIM operation: relating to general, PIN related, 3G and or GSM security and subscription related 
procedures. 

Padding: one or more bits appended to a message in order to cause the message to contain the required number of bits 
or bytes. 

Plug-in UICC: second format of UICC. 

Proactive UICC: UICC, which is capable of issuing commands to the Terminal. Part of USAT. 

Record: string of bytes within an EF handled as a single entity. 

Record number: number, which identifies a record within an EF. 

Record pointer: pointer, which addresses one record in an EF. 

Selectable application: application that is selectable by an AID according to the process described in ISO/IEC 7816-4 
[13] over the Terminal-UICC interface. 

Selectable application session: link between the application and the external world during a card session starting with 
the application selection and ending with de-selection or termination of the card session. 

UICC application toolkit procedures: defined in 3G TS 31.111 [4]. 

USIM session: USIM session is a selectable application session for a USIM application. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 



-F 


fall time 


-R 


rise time 


V,H 


Input Voltage (high) 


V,L 


Input Voltage (low) 


VoH 


Output Voltage (high) 


Vol 


Output Voltage (low) 



3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AC Access Condition 

ACK ACKnowledge 

ADF Application Dedicated File 

ADM Access condition to an EF which is under the control of the authority which creates this file 

AID Application IDentifier 

ALW ALWays 

AM Access Mode 

AM-DO Access Mode Data Object 

APDU Application Protocol Data Unit 

ARR Access Rule Reference 

ATR Answer To Reset 

BGT Block Guard Time 

BWT Block Waiting Time 

C-APDU Command APDU 
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CLA 


CLASS 


CRT 


Control Reference Template 


CLK 


Clock 


C-TPDU 


Command TPDU 


CWI 


Character Waiting Integer 


CWT 


Character Waiting Time 


DAD 


Destination ADdress 


DF 


Dedicated File 


DO 


Data Object 


EDC 


Error Detection Code byte 


EF 


Elementary File 


etu 


elementary time unit 


f 


frequency 


FCP 


File Control Parameters 


Fi 


Clock rate conversion factor 


FID 


File IDentifier 


GSM 


Global System for Mobile communications 


ICC 


Integrated Circuit Card 


I-Block 


Information Block 


ID 


IDentifier 


lEC 


International Electrotechnical Commission 


IFS 


Information Field Sizes 


IFSC 


Information Field Size for the UICC 


IFSD 


Information Field Size for the Terminal 


INF 


INFormation field 


INS 


INStruction 


I/O 


Input/Output 


ISO 


International Organization for Standardization 


Lc 


Length of Command data sent by the application layer in a case 3 or 4 Command. 


LCSI 


Life Cycle Status Information 


Le 


Maximum length of data Expected by the application layer in response to a case 2 or 4 Command. 


LEN 


LENgth 


LRC 


Longitudinal Redundancy Check 


LSB 


Least Significant Bit 


Luicc 


Exact Length of data available in the UICC to be returned in response to the case 2 or 4 Command 




received by the UICC 


MF 


Master File 


MMI 


Man Machine Interface 


MSB 


Most Significant Bit 


NAD 


Node Address byte 


NEV 


NEVer 


NPI 


Numbering Plan Identifier 


OSI 


Open System Interconnection 


PI 


Parameter 1 


P2 


Parameter 2 


P3 


Parameter 3 


PCB 


Protocol Control Byte 


PIN 


Personal Identification Number 


PPS 


Protocol and Parameter Selection 


PS 


PIN Status 


PS_DO 


PIN Status Data Object 


R-APDU 


Response APDU 


R-BIock 


Receive-ready Block 


RFU 


Reserved for Future Use 


R-TPDU 


Response TPDU 


RST 


Reset 


SAD 


Source ADdress 


S-Block 


Supervisory Block 


SC 


Security Condition 


SC_DO 


Security Condition Data Object 
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SE Security Environment 

SEID Security Environment IDentifier 

SFI Short (elementary) File Identifier 

State H High state logic level 

State L Low state logic level 

SW Status Word 

TE Terminal Equipment 

TLV Tag Length Value 

TPDU Transfer Protocol Data Unit 

USIM Universal Subscriber Identity Module 

WI Waiting time Integer 

VPP Programming power input, optional use by the card 

WTX Waiting Time eXtenstion 

WWT Work Waiting Time 

3.4 Coding Conventions 

The following coding conventions apply to the present document. 

All lengths are presented in bytes, unless otherwise stated. Each byte is represented by bits b8 to bl, where b8 is the 
most significant bit (MSB) and bl is the least significant bit (LSB). In each representation, the leftmost bit is the MSB. 

In the UICC, all bytes specified as RFU shall be set to '00' and all bits specifies as RFU shall be set to 0. If the GSM 
and/or USIM application exists on a UICC or is built on a generic telecommunications card, then other values may 
apply for the non- GSM or non-USIM applications. The values will be defined in the appropriate specifications for such 
cards and applications. These bytes and bits shall not be interpreted by a Terminal in a GSM or 3G session. 

The coding of Data Objects in the present document is according to ISO/IEC 7816-6 [16]. 



Physical Characteristics 



Two physical types of UICCs are currently specified by the present document. These are the "ID-1 UICC" and the 
"Plug-in UICC". At least one of the card sizes shall supported by a terminal that is compliant to the present document. 

The physical characteristics of both types of UICCs shall be in accordance with ISO/IEC 7816-1,2 [9,10] unless 
otherwise specified by the present document. The following additional requirements shall be applied to ensure correct 
operation in a Telecom environment. 

4.1 ID-1 UICC 

The physical characteristics of the ID-1 UICC shall conform to ISO/IEC 7816-1,2 [9,10]. 

The Terminal shall accept embossed ID-1 UICCs. The embossing shall be in accordance with ISO/IEC 781 1-1 [8] and 
ISO/IEC 781 1-3 [9]. The contacts of the ID-1 UICC shall be located on the front (embossed face, see 
ISO/IEC 7810 [7]) of the card. 



4.2 Plug-in UICC 



The Plug-in UICC shall have a width of 25 mm, a height of 15 mm, a thickness the same as an ID-1 UICC and a feature 
for orientation. 

Annex A of ISO/IEC 7816-2 [11] applies with the location of the reference points adapted to the smaller size. The three 
reference points PI, P2 and P3 measure 7,5 mm, 3,3 mm and 20,8 mm, respectively, from 0. The values in figure 2 of 
ISO/IEC 7816-2 [11] are replaced by the corresponding values of figure 4.1. 

The physical characteristics of the Plug-in UICC (Plug-in card) are defined in the present document. 
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Figure 4.1 : Plug-in UICC 



4.3 Temperature range for card operation 

The temperature range for full operational use shall be between -25°C and +70°C with occasional peaks of up to +85°C. 
"Occasional" means not more than 4 hours each time and not over 100 times during the life time of the card. 



4.4 



Contacts 



4.4.1 Provision of contacts 



4.4.1.1 



Terminal 



Contacting elements in the Terminal in positions C4 and C8 are optional, and are not used by a Telecom application 
complying to the present document. They shall present a high impedance to the UICC. If it is determined that the UICC 
is a multi-application UICC, then these contacts may be used. Contact C6 need not be provided for Plug-in cards. 



4.4.1.2 



UICC 



Contacts C4 and C8 need not be provided by the UICC. If provided, they shall not be connected internally in the UICC 
if the UICC only contains a Telecom application. Contact C6 shall not be bonded in the UICC for any function other 
than supplying Vpp. 

4.4.2 Contact activation and deactivation 

The Terminal shall connect, activate and deactivate the UICC in accordance with the Operating Procedures specified in 

ISO/IEC7816-3[12]. 
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For any voltage level, monitored during the activation sequence, or during the deactivation sequence following normal 
power-down, the order of the contact activation/deactivation shall be respected. 

It is recommended that whenever possible, the deactivation sequence defined in ISO/IEC 7816-3 [12] should be 
followed by the Terminal on all occasions when the Terminal is powered down. 

If the UICC clock is already stopped and is not restarted, the Terminal may deactivate all the contacts in any order, 
provided that all signals reach low level before Vcc leaves high level. If the UICC clock is already stopped and is 
restarted before the deactivation sequence, then the deactivation sequence specified in ISO/IEC 7816-3 [12] 
subclause 5.4 shall be followed. 

When Vpp is connected to Vcc, as allowed in this specification, then Vpp shall be activated and deactivated with Vcc, 
at the time of the Vcc activation/deactivation, as specified in the sequences of ISO/IEC 7816-3 [12] subclauses 5.2 and 
5.4. 

4.4.3 Inactive contacts 

The voltages on contacts CI, C2, C3, C6 and C7 of the Terminal shall be in the range + 0,4 volts referenced to ground 
(C5) when the Terminal is switched off with the power source connected to the Terminal. The measurement equipment 
shall have a resistance of 50 kohms when measuring the voltage on C2, C3, C6 and C7. The resistance shall be 10 
kohms when measuring the voltage on C 1 . 

4.4.4 Contact pressure 

The contact pressure shall be large enough to ensure reliable and continuous contact (e.g. to overcome oxidisation and 
to prevent interruption caused by vibration). The radius of any curvature of the contacting elements shall be greater than 
or equal to 0,8 mm over the contact area. 

Under no circumstances shall the contact force exceed 0,5 N per contact. 

Care shall be taken to avoid undue point pressure to the area of the UICC opposite to the contact area. Such pressure is 
potentially damaging to the components within the UICC. 



5 Electrical specifications of the UICC - Terminal 

interface 

The electrical specification in the present document covers the supply voltage range from 4.5V to 5.5V, 2.7V to 3.3V 
and 1.62V to 1.98 V. For each state (Vqj^, Vjjj, Vj^ and Vq^), a positive current is defined as flowing out of the entity 
(Terminal or UICC) in that state. Vpp shall not be supported by the 3V and 1.8 V technology Terminal or the 3V and 
1.8V technology UICC. 

When the UICC is in idle state, the current consumption shall not exceed 200 |iA at 1 MHz at H-25°C. When the UICC 
is in clock stop mode, the current consumption shall not exceed 100 |iA at H-25 °C. 

The clock duty cycle shall be between 40 % and 60 % of the period during stable operation. A clock cycle is defined at 
50% of Vcc from rising to rising edge or falling to falling edge. When switching clock frequencies Terminals shall 
ensure that no pulse is shorter than 100 ns which is 40 % of the shortest allowed period. 
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5.1 Specification of the 5V UICC - Terminal Interface 
5.1.1 Supply voltage Vcc (contact C1) 

The Terminal shall operate the UICC within the following limits: 

Table 5.1 : Electrical characteristics of Vcc under normal operating conditions 



Symbol 


Minimum 


Maximum 


Unit 


Vcc 


4,5 


5,5 


V 



The current consumption of the UICC shall not exceed the value given in table 6.4 during the ATR (including activation 
and deactivation). 

When the UICC is in idle state (see below) the current consumption of the card shall not exceed 200 |i A at 1 MHz and 
25°C. If clock stop mode is enabled, then the current consumption shall also not exceed 200 |iA while the clock is 
stopped. 

The Terminal shall source the maximum current requirements defined above. It shall also be able to counteract spikes in 
the current consumption of the card up to a maximum charge of 40 nAs with no more than 400 ns duration and 
amplitude of at most 200 mA, ensuring that the supply voltage stays in the specified range. 

NOTE: A possible solution would be to place a capacitor (e.g. 100 nF, ceramic) as close as possible to the 
contacting elements. 

5.1 .2 Reset (RST) (contact C2) 

The Terminal shall operate the UICC within the following limits: 

Table 5.2: Electrical characteristics of RST under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


VOH 


lOHmax = +20 mA 


Vcc-0,7 


Vcc (note) 


Vol 


l0Lmax = -200 mA 


OV (note) 


0,6 V 


tptp 


Cout = Cin = 30 pF 




400 MS 


NOTE: To allow for overshoot the voltage on RST shall remain between 
-0,3 V and Vcc+0,3 V during dynamic operation. 



5.1 .3 Programming voltage Vpp (contact C6) 

The UICC shall not require any programming voltage on Vpp. The Terminal need not provide contact C6. If the 
Terminal provides contact C6, then, in the case of the ID-1 UICC the same voltage shall be supplied on Vpp as on Vcc, 
while in the case of Plug-in UICC the Terminal need not provide any voltage on C6. Contact C6 may be connected to 
Vcc in any Terminal but shall not be connected to ground. 

5. 1 .4 Clock CLK (contact C3) 

The Terminal shall support 1 to 5 MHz. The Terminal shall supply the clock. No "internal clock" UICC shall be used. 
The duty cycle shall be between 40 % and 60 % of the period during stable operation. 
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The Terminal shall operate the UICC within the following limits: 

Table 5.3: Electrical characteristics of CLK under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


VOH 


lOHmax = +20 mA 


OJxVcc 


Vcc (note) 


Vol 


l0Lmax = -200 mA 


V (note) 


0,5 V 


tRtp 


Cout = Cin = 30pF 




9 % of period with a maximum of 
0,5 MS 


NOTE: To allow for overshoot the voltage on CLK shall remain between -0,3 V and 
Vcc+0,3 V during dynamic operation. 



5.1.5 I/O (contact C7) 

Table 5.4 defines the electrical characteristics of the I/O (contact C7). The values given in the table allow the derivation 
of the values of the pull-up resistor in the Terminal and the impedance of the drivers and receivers in the Terminal and 
UICC. 

Table 5.4: Electrical characteristics of I/O under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


V|H 


llHmax = ± 20 mA (note 2) 


0,7xVcc 


Vcc-^0,3 V 


V|L 


l|Lmax = +1 mA 


-0,3 V 


0,8 V 


VoH(notel) 


lOHmax = + 20mA 


3,8 V 


Vcc (note 3) 


Vol 


'OLmax = "1 ^A 


V (note 3) 


0,4 V 


tRtp 


Cout = Cin = 30pF 




1 MS 


NOTE 1 : It is assumed that a pull-up resistor is used in the interface device (recommended 
value: 20 kohms). 


NOTE 2: During static conditions (idle state) only the positive value can apply. Under dynamic 
operating conditions (transmission) short term voltage spikes on the I/O line may 
cause a current reversal. 


NOTE 3: To allow for overshoot the voltage on I/O shall remain between -0,3 V and 
Vcc-i-0,3 V during dynamic operation. 



5.2 Specification of the 3V UICC - Terminal Interface 
5.2.1 Supply voltage Vcc (contact 01 ) 

The Terminal shall operate the UICC within the following limits: 

Table 5.5: Electrical characteristics of Vcc under normal operating conditions 



Symbol 


Minimum 


Maximum 


Unit 


Vcc 


2,7 


3,3 


V 
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The Terminal shall be capable of sourcing the maximum current as defined in table 6.4. It shall also be able to 
counteract spikes in the current consumption of the card up to a maximum charge of 12 nAs with no more than 400 ns 
duration and an amplitude of at most 60 mA, ensuring that the supply voltage stays in the specified range. 

5.2.2 Reset (RST) (contact C2) 

The Terminal shall operate the UICC within the following limits: 

Table 5.6: Electrical characteristics of RESET (RST) under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


VOH 


lOHmax = + 20 mA 


0,8 X Vcc 


Vcc (Note) 


V 


Vol 


l0Lmax = -200 mA 


(Note) 


0,2 X Vcc 


V 


Tptp 


Gin = Gout = 30 pF 




400 


MS 


NOTE: To allow for overshoot the voltage on RST should remain between -0,3V and Vcc +0,3V 
during dynamic operations. 



5.2.3 Clock CLK (contact C3) 

The Terminal shall support 1 to 5 MHz. The Terminal shall supply the clock. No "internal clock" UICC shall be used. 
The duty cycle shall be between 40 % and 60 % of the period during stable operation. 
The Terminal shall operate the UICC within the following limits: 

Table 5.7: Electrical characteristics of Clock (CLK) under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


VoH 


IOHmax = + 20 [xA 


0,7 X Vcc 


Vcc (Note ) 


V 


Vol 


IOLmax = -20MA 


(Note ) 


0,2 X Vcc 


V 


Tptp 


Gin = Gout = 30 pF 




50 


ns 


NOTE: To allow for overshoot the voltage on CLK should remain between -0,3V and Vcc-i-0,3V 
during dynamic operations. 



5.2.4 I/O (contact C7) 



Table 5.8 defines the electrical characteristics of the I/O (contact C7). The values given in the table allow the derivation 
of the values of the pull-up resistor in the Terminal and the impedance of the drivers and receivers in the Terminal and 
UICC. 
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Table 5.8: Electrical characteristics of I/O under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


V|H 


l|Hmax = ±20MA(Note2) 


0,7 X Vcc 


Vcc-^0,3 


V 


V|L 


l|Lmax = +1 n^A 


-0,3 


0,2 X Vcc 


V 


VoH(Notel) 


loHmax = + 20 |iA 


0,7 X Vcc 


Vcc (Note 3) 


V 


Vol 


'oLmax = " 1 mA 


(Note 3) 


0,4 


V 


Tptp 


Cin = Co„ = 30pF 




1 


MS 


NOTE 1 : It is assumed that a pull-up resistor is used on the interface device (recommended value: 

20kn). 
NOTE 2: During static conditions (idle state) only the positive value can apply. Under dynamic 

operating conditions (transmissions) short term voltage spikes on the I/O line may cause 

a current reversal. 
NOTE 3: To allow for overshoot the voltage on I/O shall remain between -0,3V and Vcc-i-0,3V 

during dynamic operation. 



5.3 Specification of the 1 .8V UICC - Terminal Interface 
5.3.1 Supply voltage Vcc (contact C1 ) 

The Terminal shall operate the UICC within the following limits: 

Table 5.9: Electrical characteristics of Vcc under normal operating conditions 



Symbol 


Minimum 


Maximum 


Unit 


Vcc 


1,62 


1,98 


V 



The Terminal shall be capable of sourcing the maximum current as defined in table 6.4. It shall also be able to 
counteract spikes in the current consumption of the card up to a maximum charge of 12 nAs with no more than 400 ns 
duration and an amplitude of at most 60 mA, ensuring that the supply voltage stays in the specified range. 

5.3.2 Reset (RST) (contact C2) 

The Terminal shall operate the UICC within the following limits: 

Table 5.10: Electrical characteristics of RESET (RST) under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


VOH 


loHmax = + 20 mA 


0,8 x Vcc 


Vcc (Note) 


V 


Vol 


loLmax = -200MA 


(Note) 


0,2 X Vcc 


V 


Tptp 


Cin = Cou, = 30pF 




400 


[XS 


NOTE: To allow for overshoot the voltage on RST should remain between -0,3V and Vcc +0,3V 
during dynamic operations. 



5.3.3 Clock CLK (contact C3) 



The Terminal shall support 1 to 5 MHz. The Terminal shall supply the clock. No "internal clock" UICC shall be used. 
The duty cycle shall be between 40 % and 60 % of the period during stable operation. 
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The Terminal shall operate the UICC within the following limits: 

Table 5.11 : Electrical characteristics of Clock (CLK) under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


VOH 


IOHmax = + 20 [xA 


0,7 X Vcc 


Vcc (Note ) 


V 


Vol 


IOLmax = -20MA 


(Note ) 


0,2 X Vcc 


V 


Tptp 


Cin = Cout = 30pF 




50 


ns 


NOTE: To allow for overshoot the voltage on CLK should remain between -0,3V and Vcc+0,3V 
during dynamic operations. 



5.3.4 I/O (contact C7) 

Table 5.12 defines the electrical characteristics of the I/O (contact C7). The values given in the table allow the 
derivation of the values of the pull-up resistor in the Terminal and the impedance of the drivers and receivers in the 
Terminal and UICC. 

Table 5.12: Electrical characteristics of I/O under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


VlH 


l|Hmax = ±20MA(Note2) 


0,7 X Vcc 


Vcc-^0,3 


V 


V|L 


l|Lmax = +1 n^A 


-0,3 


0,2 X Vcc 


V 


VoH(Notel) 


lOHmax = + 20 tlA 


0,7 X Vcc 


Vcc (Note 3) 


V 


Vol 


lOLmax = " 1 mA 


(Note 3) 


0,4 


V 


Tptp 


Cin = Cou, = 30pF 




1 


MS 


NOTE 1 : It is assumed that a pull-up resistor is used on the interface device (recommended value: 

20 WQ.). 
NOTE 2: During static conditions (idle state) only the positive value can apply. Under dynamic 

operating conditions (transmissions) short term voltage spikes on the I/O line may cause 

a current reversal. 
NOTE 3: To allow for overshoot the voltage on I/O shall remain between -0,3V and Vcc-i-0,3V 

during dynamic operation. 



Initial communication establishment procedures 



6.1 



UICC activation and deactivation 



The Terminal shall activate and deactivate the contacts of the UICC according to clause 4.4.2. During activation supply 
voltage switching, as defined in clause 6.2, shall take place prior to any further activity not related to the supply voltage 
switching. 



6.2 Supply voltage switching 



The Terminal shall initially activate the UICC with the lowest voltage class available. If no ATR is received, the UICC 
shall be deactivated and activated with the next higher class, if supported by the Terminal. If an ATR is received at the 
first applied voltage class, the contents of the ATR shall be analysed by the Terminal. If the operating class used by the 
Terminal is not supported by the UICC, the Terminal shall deactivate the UICC and activate it with a supply voltage 
class indicated by the UICC. If the ATR is corrupted, the Terminal shall repeat the procedure at least 3 times using the 
same operating class before rejecting the UICC. In case of 3 consecutive corrupted ATRs, the Terminal may activate 
the UICC with the next higher class. The Terminal is restricted not to use but the next higher class in the retrial attempt 
in this case. 
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6.2.1 Supply Voltage Classes 

The supply voltage class shall be indicated in the ATR by the UICC (TA; i>2). 

Table 6.1 : Supply Voltage Classes indicated in ATR 



Symbol 


lUlinimum 


lUlaximum 


Unit 


Class 


Encoding 
(Binary) 


Vcc 


4,5 


5,5 


V 


A 


XX xxxl 


Vcc 


2,7 


3,3 


V 


B 


XX xxlx 


Vcc 


1,62 


1,98 


V 


C 


XX xlxx 


Vcc 


RFU 


RFU 


V 


D 


XX Ixxx 


Vcc 


RFU 


RFU 


V 


E 


xl xxxx 


NOTE: Class A and B values are according to ISO/IEC 781 6-3 [1 2]. Class C 
and D are a further evolution of values specified in ISO/IEC 7816- 
3 [12]. It is possible to support a range of classes. The support must 
be consecutive e.g. AB, BC. A combination like AC is not allowed. 



6.2.2 Power Consumption of the UICC during ATR 

The maximum power consumption of the UICC during ATR is specified in tables 6.2a and 6.2b. The UICC power 
consumption during the ATR shall conform to the voltage class indicated in the ATR. If the UICC supports several 
supply voltage classes, each class shall conform to the corresponding maximum ATR power consumption, as specified 
in tables 6.2a and 6.2b. This is required because the terminal is not aware of the power consumption of the UICC until 
the ATR is received and an application is selected. 

Table 6.2a: Power Consumption that applies during ATR at maximum external clock 



Symbol 


Voltage 
Class 


Maximum 


Unit 


Ice 


A 


10 


mA 


Ice 


B 


7.5 


mA 


Ice 


C 


5 


mA 


Ice 


D 


RFU 


mA 


Ice 


E 


RFU 


mA 



Table 6.2b: Power Consumption that applies during ATR at 4 MHz 



Symbol 


Voltage 
Class 


Maximum 


Unit 


Ice 


B 


6 


mA 


Ice 


C 


4 


mA 


Ice 


D 


RFU 


mA 


Ice 


E 


RFU 


mA 


NOTE: 4 IVIHz is the maximum clock speed 
specified in GSM for 3V and below 



6.2.3 Application Related Electrical Parameters 

The power consumption of a UICC depends upon the supply voltage class and the application it is running. The power 
consumption of the UICC is restricted to the values indicated in tables 6.2a and 6.2b until an application is selected. An 
application is considered selected when the access condition is successfully verified. If no access condition is required 
for the application, the application is considered selected when an application related command is executed within the 
selected application. Selecting the application and performing a STATUS command is not considered to be the 
execution of an application command for these purposes. 
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The Terminal retrieves the application power consumption requirements by selecting the application. It then gets back 
the application power consumption indication in the response of the SELECT command. It may as well issue a 
STATUS command within the application and get this information in the response of the command. 

Table 6.3: Maximum Power Consumption of the UICC during the UICC Session 



Symbol 


Voltage 
Class 


Maximum 


Unit 


Ice 


A 


60 


mA 


Ice 


B 


50 


mA 


Ice 


C 


30 


mA 


lee 


D 


RFU 


mA 


lee 


E 


RFU 


mA 


NOTE: All values assume the maximum external clock. 



Applications may specify their own maximum power consumption values, up to the maximum specified in table 6.3. 

If an application doesn't indicate its consumption, the terminal shall assume the maximum application power 
consumption is as specified in table 6.4. 

The minimum power supply that the terminal shall be able to supply to the UICC during application session at 
maximum clock speed is specified in table 6.4: 

Table 6.4: Minimum Power supply by the Terminal during the UICC Session 



Symbol 


Voltage 
Class 


Minimum 


Unit 


Ice 


A 


10 


mA 


lee 


B 


7.5 


mA 


Ice 


C 


5 


mA 


lee 


D 


RFU 


mA 


lee 


E 


RFU 


mA 


NOTE: All values assume the maximum external clock. 



6.3 



Answer To Reset content 



The ATR is the first string of bytes sent from the UICC to the Terminal after a reset has been performed. The ATR is 
defined in ISO/IEC 7816-3 [12]. 

The Terminal shall be able to receive interface characters for transmission protocols other than T=0 and T=l, historical 
bytes and a check byte, even if only T=0 and T=l are used by the Terminal. 

T=15 parameters shall be returned by the UICC. 

Example ATRs are listed in Annex D of the present document. 

6.3.1 Coding of historical bytes 

The historical bytes indicate to the external world how to use the card. The information carried by the historical bytes of 
the UICC follows clause 8 of ISO/IEC 7816-4 [13]. 

The category indicator is the first byte sent by the UICC. Its value shall be '80' which means that the historical bytes are 
coded in COMPACT-TLV data objects. 

The first information sent by the card shall be the "card data service" data object. This data object is introduced by tag 
'31'. The second information sent by the card shall be the "card capabilities" data object. This data object is introduced 
by tag '73'. The other data objects are optional. 
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6.3.2 Speed enhancement 



The Terminal and the UICC shall at least support (F,D) = (512,8) and (512,16) in addition to (372,1), the default values. 
However, other values may also be supported. If the Terminal requests PPS using values other than those above then the 
PPS procedure shall be initiated accordingly. The value of the transmission factors F and D is given by the UICC in 
TAiofthe ATR. 



6.4 PPS procedure 

The Terminal and the UICC shall support the PPS procedure in order to use other transmission parameters as default 
values. The alternative parameters are indicated in the ATR. The interpretation of these parameters is according to 
ISO/IEC7816-3[12]. 

6.5 Cold Reset 

The cold reset is performed according to clause 5.3.2 of ISO/IEC 7816-3 [12] and the UICC shall enter the negotiable 
mode. After a cold reset, the security status shall be reset. 

6.6 Warm reset 

The warm reset is performed according to clause 5.3.3 of ISO/IEC 7816-3 [12] and the UICC shall enter either the 
negotiable or the specific mode. After a warm reset, the security status shall be reset. 

6.7 Clock stop mode 

The UICC shall support the clock stop procedure as defined in this clause. 

The Terminal shall wait at least 1860 clock cycles after having received the last character, including the guard time (2 
etu), of the response before it switches off the clock (if it is allowed to do so). It shall wait at least 744 clock cycles 
before it sends the first command after having started the clock. 

6.8 Bit/character duration and sampling time 

The bit/character duration and sampling time specified in ISO/IEC 7816-3 [12], subclause 6.3.2 are valid for all 
communications . 

6.9 Error handling 

Following receipt of an ATR, which is not in accordance with this specification, e.g. because of forbidden ATR 
characters or too few bytes being transmitted, the Terminal shall perform a Reset. The Terminal shall not reject the 
UICC until at least three consecutive wrong ATRs are received. 

During the transmission of the ATR, the error detection and character repetition procedure specified in 

ISO/IEC 7816-3 [12], subclause 6.3.3, is optional for the Terminal. For the subsequent transmission on the basis of T=0 

this procedure is mandatory for the Terminal. 

For the UICC the error detection and character repetition procedure is mandatory for all communications using T=0. 

6.10 Compatibility 

Terminals operating at 5V only and that are compliant to the electrical parameters defined in subclause 5.1 and 
subclauses can operate with a 3V or a 1.8V Technology Smart Card according to this specification. 



£75/ 



3G TS 31.101 version 3.2.0 Release 1999 25 ETSI TS 131 101 V3.2.0 (2000-07) 



For compatibility with existing terminals, UICCs that are used in applications where the supply voltage class detection 
is based on the STATUS response procedure (see subclause 6.2.3) shall support this procedure in addition to the supply 
voltage class indication in the ATR as defined in this standard. 

In case the UICC does not support any supply voltage indication, the UICC shall be treated as a 5V only card by the 
Terminal. 



7 Transmission Protocols 

This clause defines the transmission protocols used to exchange data between the terminal and the UICC. The structure 
and processing of commands initiated by the terminal for transmission control and for specific control in asynchronous 
half duplex transmission protocols will be described. 

Two different protocols are defined, the character based protocol T=0 and the block based protocol T=l. 

The T=0 protocol is mandatory for the UICC and the Terminal. The T=l protocol is mandatory for the Terminal and 
optional for the UICC. 

The protocol starts after either the answer to reset or a successful PPS exchange. Other parameters provided in the ATR 
and relevant to a specific protocol are defined in the respective parts of this clause. 

The protocol applies a layering principle of the OSI-reference model. Four layers are considered. The layers are: 

the physical layer. The contained definitions are valid for T=0 and T=l. 

the data link layer, which consists of: 

a character component; 

a block component; 
- block identification; 

send blocks; 

detect transmission and sequence errors; 

handle errors; 

synchronise the protocol. 

the transport layer, which defines the transmission of application-oriented messages specific to each protocol. 

the application layer, which defines the exchange of messages according to an application protocol that is 
common to both protocols. 
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Figure 7.1: Layers 



7.1 Physical Layer 



Both protocols T=0 and T=l shall use the physical layer and character frame as defined in 7.2.1. 



7.2 Data Link Layer 



This subclause describes the timing, specific options and error handling for the protocols T=0 and T=l. 

7.2.1 Character Frame 

A character that is transmitted over the I/O line is embedded in a character frame. 

Before the transmission of a character, the I/O line shall be in state H. 

A character consists of 10 consecutive bits (see Figure 7.2): 

1 start bit in state L; 

8 bits, which comprise the data byte; 

1 even parity checking bit. 

The parity bit is set, in a way, that there is an even number of bits set to '1' including the parity bit in the character 
frame. 

The time origin is fixed as the mean between the last observation of state H and the first observation of state L. The 
receiver shall confirm the existence of a start bit before 0.7 etu (receiver time). Then the subsequent bits shall be 
received at intervals of (n + 0.5 + 0.2) etu (n being the rank of the bit). The start bit is bit 1 . 

Within a character, the time from the leading edge of the start bit to the trailing edge of the nth bit is (n + 0.2) etu. 

The interval between the leading edges of the start bits of two consecutive characters is comprised of the character 
duration (10 + 0.2) etu, plus a guardtime. Under error free transmission, during the guardtime both the UICC and the 
terminal shall be in reception mode (I/O line in state H). 
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Figure 7.2: Character Frame 

The data shall always be passed over the I/O line with the most significant byte first. The order of bits within a byte 
(that is, whether the least significant or most significant bit is transferred first) is specified in character TS returned in 
the answer to reset. 

7.2.2 Transmission Protocol T=0 

The T=0 is a half -duplex asynchronous character based transmission protocol. 

All commands using the protocol T=0 are initiated from the terminal by sending a five byte header, which informs the 
UICC what to do. The terminal will always act as master and the UICC as a slave. The direction of the transmission is 
assumed to be known to both the UICC and the terminal. 

7.2.2.1 Timing and specific options for characters in T=0 

The minimum interval between the leading edge of the start bits of two consecutive characters shall be at least 12 etus. 

The maximum interval between the start leading edge of any character sent by the UICC and the start leading edge of 
the previous character sent by either by the UICC or the terminal i.e. the WWT. The value of the WWT shall not exceed 
960 X WI X Fi/f WI is an integer received in the specific interface byte TC2. If no TC2 is available, default value of WI 
is 10. The clock rate conversion factor, Fi, may be indicated in TAl . If TAl is absent the default value 372 is used. 

If the WWT is exceeded, the terminal shall initiate a deactivation within 960 etus. 

The minimum interval between the leading edges of the start bits of two consecutive characters sent in opposite 
direction shall be 16 etus. 

7.2.2.2 Command Header 

A command is always initiated by the terminal which sends an instruction to the UICC in the form of a five byte-header 
called the command header. The command header is comprised of five consecutive bytes, CLA, INS, PI, P2, and P3. 

These bytes together with any data to be sent with the command form the Command Transport Protocol Data Unit 
(C-TPDU) for T=0. The mapping of the C-APDU onto the C-TPDU is described in clause 7.3. 

The terminal transmits the header to the UICC and waits for a procedure byte. 

7.2.2.3 Command Processing 

When the UICC has received the command header, a response containing a procedure byte shall be sent to the terminal. 
Both the terminal and the UICC shall be able to keep track of the direction of the data flow and who has the access to 
the I/O-line. 

7.2.2.3.1 Procedure bytes 

The procedure byte indicates to the terminal what action it shall take next. 

Procedure bytes are used to keep up the communication between the terminal and the UICC. They shall not be 
transmitted to the Application Layer. 

The coding of the procedure byte and the action that shall be taken by the terminal is shown in table 7.1. 
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Table 7.1 : Procedure Byte coding 



Byte 


Value 


Action 


ACK 


Equal to INS byte 


All remaining data bytes shall be transferred by the terminal, or 
the terminal shall be ready to receive all remaining data bytes 
from the UICC. 


Equal to complement of INS byte 
(INS) 


The next data byte shall be transferred by the terminal, or the 
terminal shall be ready to receive the next data byte from the 
UICC. 


NULL 


'60' 


The NULL-byte requests no further data transfer and the 
terminal shall only wait for a character conveying a procedure 
byte. This behaviour provides additional work waiting time as 
defined in this section. 


SW1 


'61' 


The terminal shall wait for a second procedure byte then send a 
GET RESPONSE command header to the UICC with a 
maximum length of 'XX', where 'XX' is the value of the second 
procedure byte (SW2). 


'6C' 


The terminal shall wait for a second procedure byte then 
immediately repeat the previous command header to the UICC 
using a length of 'XX', where 'XX' is the value of the second 
procedure byte (SW2). 



After these actions, the terminal shall wait for a further procedure byte or status word. 

7.2.2.3.2 Status bytes 

The status bytes SWl SW2 form an end sequence indicating the status of the UICC at the end of a command. A normal 
ending of a command is indicating by SWl SW2 = '90 00'. 

Table 7.2: Status Byte Coding 



Byte 


Value 


Action 


SWl 


'6X' or '9X' (except '60', '61', and 
'6C') 


The terminal shall wait for a further status word (SW2). 
The terminal shall return the status words (together with any 
appropriate data) to the Application Layer and shall wait for 
another C-APDU. 



7.2.2.4 



Error detection and correction 



The error detection and correction procedure is mandatory for T=0 protocol except for the Terminal during the ATR- 
procedure. 

An error, from the receiver's point of view, is defined by an incorrect parity. The error is indicated on the I/O-line, 
which is set to state L after (10.5 ±0.2) etus after the leading edge of the start bit for the character. The I/O line shall be 
in state L for a maximum of 2 etus and a minimum of 1 etu. 

If the UICC or terminal as receiver detects a parity error within 1 1 ±0.2 etus starting from the leading edge of the start 
bit, in a character just received, it shall set I/O to state L to indicate the error to the sender - see figure 7.2 "character 
frame". 

If the transmitter detects an error, the character shall be sent again after a minimum delay of 2 etus. 



7.2.3 Transmission protocol T=1 



The T=l protocol is a half-duplex asynchronous block based transmission protocol. The protocol may be initiated after 
an ATR due to a Warm Reset,or a successful PPS exchange. 
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The communication starts with a block sent by the terminal to the UICC. The right to send a block keeps alternating 
between the terminal and the UICC. A block is the smallest data unit, which can be sent and can contain either 
application data or transmission control data. A check of the received data might be performed before further processing 
of the received data. 



7.2.3.1 



Timing and specific options for blocks sent with T=1 



This subclause defines options regarding timing, information file sizes and error detection parameters for blocks sent 
withT=l. 



7.2.3.1.1 



Information field size 



The IFSC defines the maximum length of the information field of blocks that can be received by the UICC. The default 
value of the IFSC is 32 bytes another value may be indicated in TA3 of the ATR. 

The IFSD defines the maximum length of the information field of blocks that the terminal can receive. IFSD has a 
default value of 32 bytes and may be adjusted during the card session. The maximum value of the IFSD is 254 bytes. 

7.2.3.1.2 Character waiting integer 

CWI is used to calculate CWT and shall be in the range from to 5. The value is set in bits b4 to bl in TB3. 

7.2.3.1 .3 Character waiting time 

CWT is defined as the maximum delay between the leading edges of two consecutive characters in the block. 



T<CWT 



Figure 7.3: Character waiting time 

The value of CWT may be calculated from the following equation: CWT = (11+ 2*^*') etu. 



7.2.3.1.4 



Block waiting time 



B WT is defined as the maximum delay between the leading edge of the last character of the block received by the card 
and the leading edge of the first character of the next block sent by the card. 



<- Last character of a block sent by 
theTerminal 



First character of next block sent by the UICC-> 
I BWT 



Figure 7.4: Block waiting time 

BWT is used to detect an unresponsive card. 

7.2.3.1.5 Block guard time 

BGT is defined as the minimum delay between the leading edge of two consecutive characters sent in opposite 
directions. The value of BGT shall be 22 etu. 
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<- Last character of a block sent by the 
Terminal 



First character of next block sent by the UICC-> 
I BGT 



Figure 7.5: Block guard time 

The delay between the last character of a block received by the UICC and the first character of the next block sent from 
the UICC shall be in the interval: 

BGT < delay < BWT. 

7.2.3.1 .6 Waiting time extension 

WTX is a parameter used to ask for more time to process a command. 

7.2.3.1 .7 Error detection code 

The parameter TCi in the ATR is used to define which error detection code to use. LRC shall be used (bl=0). All other 
bits in TCi are RFU and shall be set to 0. 



7.2.3.2 



Block frame structure 



The protocol consists of blocks, which are transmitted between the Terminal and the UICC. Each block has the 
following structure: 

Table 7.3: Block frame structure 



Prologue field 


Information field 


Epilogue field 


NAD 


PCB 


LEN 


INF 


EDC 


1 byte 


1 byte 


1 byte 


0-254 bytes 


1 byte 



The prologue field and the epilogue field are mandatory. The Information field is optional. 
7.2.3.2.1 Prologue field 

The prologue field is divided into the following three mandatory fields: 

- Node address byte (NAD), 1 byte; 

- Protocol Control byte (PCB), 1 byte; 

- Length (LEN), 1 byte. 



7.2.3.2.1.1 



Node address byte 



The NAD-byte identifies the source and the intended destination of the block. The NAD may also be used to distinguish 
between different logical connections if they coexist. Below is the structure of the NAD-byte: 

Table 7.4: Node address byte 



b8 


b7 b6 b5 


b4 


b3 b2 b1 


Unused 


DAD 


Unused 


SAD 



In the first block sent from the Terminal, a logical connection is set up based on the addresses in SAD and DAD. 
Subsequent blocks with an NAD containing the same pair of addresses are associated with the same logical connection. 
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Only the default value SAD=DAD=0 shall be supported. All other combinations are not allowed. 



7.2.3.2.1.2 



Protocol Control Byte 



All information needed to control the transmission is transferred in the protocol control byte PCB. The coding of the 
PCB-byte specifies the type of block. In the T=l protocol the following three different types of blocks are supported: 

Information block, I-block which is used to transfer command and response APDUs; 

Receive-ready block, R-block, which is used to transfer acknowledgements; 

Supervisory block, S -block, which is used to send control information. 

The tables below present the coding of the PCB-byte for each block-type, starting with the I-block. 

Table 7.5: Coding of PCB for an I-block 



b8 


b7 


b6 


b5 1 b4 1 b3 1 b2 1 b1 





Sequence 

number, 

N{S) 


Chaining, 

more-data 

bit, M 


RFU 



Table 7.6: Coding of PCB for an R-block 



bS 


b7 


b6 


b5 


b4 1 b3 1 b2 1 b1 


1 








Sequence 
number N(R) 


See table 7.5 



Table 7.7: Bit b4-b1 in the PCB-byte for the R-block 



b4 


b3 


b2 


b1 


Value 


Meaning 














'0' 


Error free 











1 


'1' 


EDC and/or parity error 








1 





'2' 


Other errors 


X 


X 


X 


X 


'X' 


Other values are RFU 



Table 7.8: Coding of PCB for an S-block 



bS 


b7 


b6 


b5 1 b4 1 b3 1 b2 1 b1 


1 


1 


X 


See table 7.9 



Table 7.9: Bits b5-b1 of PCB for an S-block 



b5 


b4 


b3 


b2 


b1 


Value 


Meaning 

















'0' 


Resynchronization 














1 


'1' 


Information field 











1 





'2' 


Abortion 











1 


1 


'3' 


Extension of BWT 








1 








'4' 


Error on VPP State, see NOTE 


X 


X 


X 


X 


X 


'X' 


Other values are RFU 


NOTE: Not used by UlCCs and Terminals conforming to this specification. 



The coding of b6 indicates wether it is a request (b6=0) or a response (b6=l). 



7.2.3.2.1.3 



Length 



The length byte codes the number of bytes in the Information field of the block. The number of bytes in the information 
field may vary in the range from to 254 bytes, depending on the type of block. 
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The value LEN='00' indicates that the information field is absent and the value 'FF' is RFU. 

7.2.3.2.1 .4 Information field 

The information field, INF, is optional and it depends on the type of the block what the field will be used for. 

Table 7.10: Information field 



Type of block 


INF used for 


l-block 


Transfer command and response APDUs. 


R-block 


Not used 


S-block 


Transfers non application related information: 

• INF shall be present (single byte) to adjust 
IFS with WTX 

• INF shall be absent to signal error on 
VPP, or managing chain abortion or 
resynchronisation 



7.2.3.2.2 



Epilogue field 



The epilogue field contains the error detection code-byte (EDC), which transfers the error detection code of the 
transmitted block. 

The LRC as defined in ISO/IEC 7816-3 [12] shall be used. 



7.2.3.2.3 



Block notations 



7.2.3.2.3.1 l-block 

The I-blocks are denoted as follows: I(N(S), M) where: 

N(S) is the send-sequence number of the block; 

M is the more-data bit used in the chaining function. 

7.2.3.2.3.2 R-block 

The R-block is denoted as follows: R(N(R)), where: 
N(R) is the number of the expected I-block. 



7.2.3.2.3.3 



S-block 



S-blocks are always used in pairs. A S(request) is always followed by a S(response) block. The S-blocks are denoted as 
follows: 

S(RESYNCH request), a request of a resynchronization; 
S(RESYNCH response), an acknowledge of the resynchronization; 
S(IFS request), an offering of a maximum size of the information field; 
S(IFS response), an acknowledge on the information field; 
S(ABORT request), a request to abort the chain function; 
S(ABORT response), an acknowledge of the abortion of the chain function; 
S(WTX request), a request for an extension of the waiting time; 
S(WTX response), an acknowledge of the extension of the waiting time. 

7.2.3.3 Error free operation 

This subclause describes the rules for error free operation with T=l. 

The first block sent to the UICC shall be either an l-block with N(S)=0 or an S-block. 
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If a sender S sends I(Ns (S), 0), the block is acknowledged by the receiver R with a I(Nr (S), M). The contents of 
I(Nr (S)) indicates data transfer data and that the receiver is ready to receive the next block from the sender. 

If a sender S sends an I(Ns(S), 1) it should be acknowledged by the receiver R with R(Nr(R)), where Ns(S) i^ 
Nj(R), to indicate that the received block was correct and that the receiver is ready to receive the next block. 

The UICC might need more than BWT to process the previously received block, a S(WTX request) is sent by the 
UICC. The terminal shall acknowledge with a S(WTX response). The new allocated time starts at the leading 
edge of the last character of the S(WTX response). 

To change the value of IFSD, the terminal sends an S(IFS request). The request shall be acknowledged by the 
UICC with an S(IFS response) with the same INF. The new IFSD is assumed to be valid as long as no new 
S(IFS request) has been received by the UICC. 

When the receiver has received the number of characters as indicated in the value of the LEN and EDC the 
receiver returns the right to send. 

7.2.3.4 Error handling for T=1 

This subclause contains a description of the rules used to control the error handling for the T=l protocol. 

The block component of the data link layer shall be able to handle errors like: 

- BWT time-out; 

receive an invalid block, i.e. a block with parity errors, EDC error, invalid PDC, invalid length, lost synchronisation 
or failure to receive relevant S(... response) after a S(... request). 

Resynchronisation of the protocol may be attempted at three consecutive levels. If one level is unsuccessful, then the 
next level is tried. 

For the terminal, the three levels are: 
Retransmission of blocks. 

- Use of S(RES YNCH request). 
Card reset or deactivation. 

For the UICC, the three levels are: 
Retransmission of blocks. 

- Use of S(RES YNCH response). 

- Without action by the terminal, the UICC becomes unresponsive. 

7.2.3.4.1 Protocol initialisation 

After an ATR due to a Warm reset or successful PPS procedure, the communication between the terminal and the UICC 
can be initiated. But if the terminal fails to receive an error-free block, in the beginning of the protocol, a maximum of 
two more successive attempts to receive the block is allowed before resetting or a deactivation of the card takes place. 

If the response on the first block sent by the terminal is not sent within BWT, the terminal shall send a R(0). 

When the protocol has been initiated and the first block received by the UICC is invalid, the UICC responses with a 
R(0). 

If the terminal fails to receive an error-free block during a card-session, a maximum of two further attempts is allowed 
before a S(RESYNCH request) is sent. 

7.2.3.4.2 Block dependent errors 

When an I-block has been sent and a BWT time-out occurs or an invalid block has been received ( with the terminal), 
an R-block is sent, which requests with its N(R) for the expected I-block with N(S)=N(R). 

When an R-block was sent and an invalid block is received or BWT time-out, the R-block shall be resent. 
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When an S(. . . request ) has been sent and either a BWT time-out occurs (with the terminal) or the received response is 
not a S(. . . response), the S(. . . response) shall be resent. But if an S(. . . response) has been sent and either an invalid 
block is received or a BWT time-out occurs (with the terminal), an R-block shall be sent. 

When the UICC sends an S(IFS request) and receives an invalid block, the S(IFS request) shall be resent maximum one 
extra time to receive an S(IFS response). After the second failure to receive an S(IFS response), the UICC shall stay in 
reception mode. 

7.2.3.5 Chaining 

Chaining allows the terminal or the UICC to transfer information, which is longer than IFSC or IFSD. If information 
longer than IFSC or IFSD is transferred, the information should be divided into pieces, each has a length < IFSC or 
IFSD. Each piece should be sent in an I-block using the chaining function. 

The value of the M-bit in the PCB byte of the I-block controls the chaining function according to: 

- M = 0, the block is not chained to the next block; 

M = 1 , the block is chained to the next block, which shall be an I-block. 

When a receiver receives a more-data I-block, a R(N(R)) shall be sent. N(R)= N(S) of the expected I-block. At least one 
chained block should follow. 

A physical error, e.g. buffer overrun, in the UICC can cause an error in a chaining process. To abort a chain an 
S(ABORT request) can be sent by either the sender or the receiver. The request shall be answered with an S(ABORT 
response). When the S(ABORT response) has been received an R-block may be sent to either the terminal or the UICC 
to give back the right to send to either. 

7.2.3.5.1 Rules for chaining 

When the terminal is the receiver, the terminal shall accept a sequence of chained I-blocks sent from the UICC. 
The length of each block is < IFSD. 

When the UICC is the receiver, the UICC shall accept a sequence of chained I-blocks sent from the terminal. 
The length of each block shall be equal to the value of IFSC except for the last block whose length can be any 
value in the range of to IFSC. 

When the terminal is the sender, all I-blocks of a chain shall have LEN = IFSC bytes except for the last, which 
could have a value in the range of to IFSC. 

When the UICC is the sender, all I-blocks of a chain shall have LEN < IFSD bytes per block. 

When the UICC is the receiver and receives block with LEN > IFSC, the block shall be rejected and 
acknowledged with a R-block with bits bl-b4 in the PCB-byte having a value of 2. 

For reasons of efficiency, it is not recommended to send empty I-blocks. 

7.3 Transport Layer 

This subclause describes how the APDU are transported between the terminal and the UICC. For definition of the cases 
for Data in APDUs see subclause 7.4. 

7.3.1 Transportation of an APDU using T=0 

This subclause describes the mapping of C- APDUs and R- APDUs for T=0 protocol, the APDU exchange and the use of 
the GET RESPONSE command for case 2 and case 4. 
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7.3.1.1 



Mapping of APDUs to TPDUs 



The mapping of the C-APDU onto the T=0 command header is dependent upon the case of the command. The mapping 
of the data (if present) and status returned by the UICC onto the R-APDU is dependent upon the length of the data 
returned. 

Procedure bytes '61XX' and '6CXX' are returned by the UICC to control exchanges between the Transport Layer of the 
Terminal and the UICC, and should never be returned to the Application Layer of the Terminal. Command processing 
in the UICC is not complete if it has returned procedure bytes '61XX' or '6CXX'. 

Normal status on completion of processing a command is indicated if the UICC returns status words '9000' to the 
Transport Layer of the Terminal. The Transport Layer of the Terminal shall discontinue processing of a command (i.e. 
pass the R-APDU to the Application Layer and wait for a further C-APDU from the Application Layer) on receipt of 
any status words (but not on receipt of procedure bytes '61xx' and '6Cxx') from the UICC. For case 4 commands only, 
immediately following successful transmission of command data to the UICC, the Transport Layer of the Terminal shall 
continue processing the command if warning status bytes ('62xx' or '63xx') or application related status bytes ('9xxx' 
except '9000') are received. 

The following descriptions of the mapping of data and status returned by the UICC onto the R-APDU are for 
information, and apply only after the UICC has completed processing of the command, successfully or otherwise, and 
all data (if present) has been returned by the UICC under the control of '61XX' and '6CXX' procedure bytes. Detailed 
use of the INS, INS, and '60' procedure bytes is not described. 

The status returned by the UICC shall relate to the most recently received command. Where a GET RESPONSE 
command is used to complete the processing of a case 2 or case 4 command, any status returned by the UICC after 
receipt of the GET RESPONSE command shall relate to GET RESPONSE command, not to the case 2 or case 4 
command which it completes. 

7.3.1.1.1 Casel 

The C-APDU is mapped onto the C-TPDU by assigning the value '00' to the body part (P3 = '00'). 



Application Layer (C-APDU) 
Transport Layer (C-TPDU) 

Transport Layer (R-TPDU) 
Application Layer (R-APDU) 

Figure 7.6 

The flow of the exchange is as follows: 

1 The Transport Layer of the Terminal shall send the T=0 command header to the UICC. 

2 On receipt of the command header the UICC, under normal or abnormal processing, shall return status to the 
Transport Layer of the Terminal. 

(The UICC shall analyse the T=0 command header to determine whether it is processing a case 1 command or a 
case 2 command requesting all data up to the maximum length available.) 

3 On receipt of status from the UICC, the Transport Layer of the Terminal shall discontinue processing of the 
command. 

See Annex C for details of the exchanges between the Transport Layer of the Terminal and the UICC. 

The status words returned to the Transport Layer of the Terminal from the UICC after completion of processing of the 
command are mapped onto the mandatory trailer of the R-APDU without change. 



Terminal 
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Command Processing 
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SW1||SW2 


SW1||SW2 
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7.3.1.1.2 Case 2 

The C-APDU is mapped onto the C-TPDU without any change. 



Application Layer (C-APDU) 
Transport Layer (C-TPDU) 



Transport Layer (R-TPDU) 
Application Layer (R-APDU) 



Terminal 




CLA INS P1 P2 Le 




CLA INS P1 P2 P3=Le 


^ 






Le bytes of DATA||SW1 ||SW2 


<- 


Le bytes of DATA||SW1 ||SW2 





UICC 



Command Processing 



Le bytes of DATA||SW1 ||SW2 



Figure 7.7 

The flow of the exchange is as follows: 

1 The Transport Layer of the Terminal shall send the T=0 command header to the UICC. 

2 On receipt of the command header the UICC: 

a) under normal processing shall return data and status to the Transport Layer of the Terminal. The UICC shall 
use procedure bytes '6Cxx' (and if required, procedure bytes '61xx') to control the return of data (see below) 

or 

b) under abnormal processing shall return status only to the Transport Layer of the Terminal. 

3 On receipt of the data (if present) and status from the UICC, the Transport Layer of the Terminal shall 
discontinue processing the command. 

See Annex C for details of the exchanges between the Transport Layer of the Terminal and the UICC, including use of 
the '61XX' and '6CXX' procedure bytes. 

The R-TPDU is mapped onto the R-APDU without any change. 

The data (if present) and status returned to the Transport Layer of the Terminal from the UICC after completion of 
processing of the command are mapped onto the R-APDU as follows: 

The data returned (if present) is mapped onto the conditional body of the R-APDU. If no data is returned, the 
conditional body of R-APDU is left empty. 

The status returned is mapped onto the mandatory trailer of the R-APDU without change. 

7.3.1.1.3 Case 3 

The C-APDU is mapped onto the C-TPDU without any change. Lc is a value between 1 and 255. 



Application Layer (C-APDU) 
Transport Layer (C-TPDU) 



Transport Layer (R-TPDU) 
Application Layer (R-APDU) 



Terminal 



CLA INS P1 P2 Lc [Lc bytes of DATA] 



CLA INS P1 P2 P3=Lc [Lc bytes of 
DATA] 



SW1||SW2 



SW1||SW2 



UICC 



Command Processing 



SW1||SW2 



Figure 7.8 

The flow of the exchange is as follows: 

1 The Transport Layer of the Terminal shall send the T=0 command header to the UICC. 

2 On receipt of the command header, if the UICC: 
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a) returns a procedure byte, the Transport Layer of the Terminal shall send the data portion of the conditional 
body of the C-APDU to the UICC under the control of procedure bytes returned by the UICC 

or 

b) returns status, the Transport Layer of the Terminal shall discontinue processing of the command. 

3 If processing was not discontinued in step 2(b), the UICC shall return status following receipt of the conditional 
body of the C-APDU and completion of processing the command. 

4 On receipt of status from the UICC, the Transport Layer of the Terminal shall discontinue processing the 
command. 

See Annex C for details of the exchanges between the Transport Layer of the Terminal and the UICC. 

The status words returned to the Transport Layer of the Terminal from the UICC after completion of processing of the 
command, or the status words returned by the UICC that caused the Transport Layer of the Terminal to discontinue 
processing of the command, are mapped onto the R-APDU without change. 

7.3.1.1.4 Case 4 

The C-APDU is mapped onto the C-TPDU by cutting off the last byte (Le) of the body. 



Application Layer (C-APDU) 
Transport Layer (C-TPDU) 



Transport Layer (R-TPDU) 
Application Layer (R-APDU) 



Terminal 



CLA INS PI P2 Lc [Lc bytes of DATA] Le 



CLA INS P1 P2 P3=Lc [Lc bytes of DATA] 



SW1||SW2 (61 XX, XX=Luicc) 



Get Response, P3 = Luicc 



Luicc byte of DATA||SW1||SW2 



Luicc byte of DATA||SW1 ||SW2 



<- 
^ 



UICC 



Command Processing 



SW1||SW2(61XX) 



Supply of Response Data 



Luicc byte of 
DATA||SW1||SW2 



Figure 7.9 

The flow of the exchange is as follows: 

1 The Transport Layer of the Terminal shall send the T=0 command header to the UICC. 

2 On receipt of the command header, if the UICC: 

a) returns a procedure byte, the Transport Layer of the Terminal shall send the data portion of the conditional 
body of the C-APDU to the UICC under the control of procedure bytes returned by the UICC 

or 

b) returns status, the Transport Layer of the Terminal shall discontinue processing of the command. 

3 If processing was not discontinued in step 2(b), following receipt of the conditional body of the C-APDU, the 
UICC: 

a) under normal processing, shall return procedure bytes '61xx' to the Transport Layer of the Terminal 
requesting the Transport Layer of the Terminal to issue a GET RESPONSE command to retrieve the data 
from the UICC 

or 

b) under abnormal processing, shall return status only to the Transport Layer of the Terminal. 

4 On receipt of the procedure bytes or status returned in step 3, if the UICC: 
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a) returned '61xx' procedure bytes as in step 3(a), the Transport Layer of the Terminal shall send a GET 
RESPONSE command header to the UICC with P3 set to a value less than or equal to the value contained in 
the 'xx' byte of '61xx' procedure bytes 

or 

b) returned status as in step 3(b) that indicates a warning ('62xx' or '63xx'), or which is application related 
('9xxx' but not '9000'), the Transport Layer of the Terminal shall send a GET RESPONSE command with 
Le='00' 

or 

c) returned status as in step 3(b) other than that described in step 4(b), the Transport Layer of the Terminal shall 
discontinue processing of the command. 

5 If processing was not discontinued in step 4(c), the GET RESPONSE command shall be processed according to 
the rules for case 2 commands. 

The first R-TPDU from the UICC indicates that the UICC performed the command correct and that the UICC has more 
data of length Luicc bytes to transfer. The first R-TPDU is mapped without any changes onto the R-APDU. 

See Annex C for details of the exchanges between the Transport Layer of the Terminal and the UICC, including use of 
the '61XX' and '6CXX' procedure bytes. 

7.3.1.1.5 Use of Procedure Bytes '61 xx' and '6Cxx' 

The UICC returns procedure bytes '61xx 'and '6Cxx' to the Transport Layer of the Terminal to indicate to it the 
manner in which it should retrieve the data requested by the command currently being processed. These procedure bytes 
are only used when processing case 2 and 4 commands using T=0. 

Procedure bytes '61xx' instruct the Transport Layer of the Terminal to issue a GET RESPONSE command to the 
UICC. P3 of the GET RESPONSE command header is set to 'xx'. 

Procedure bytes '6Cxx' instruct the Transport Layer of the Terminal to immediately resend the previous command 
header setting P3 = 'xx' . 

Usage of these procedure bytes during error free processing with case 2 and 4 commands is as follows. In the case of an 
error, the UICC may return status indicating error or warning conditions instead of the '61xx' or '6Cxx' response. 

7.3.1.1.5.1 Case 2 Commands 

1 . If the UICC receives a case 2 command header and Le = '00' or Le > Luicc, it shall return : 

a) procedure bytes '6C Luicc' instructing the Transport Layer of the Terminal to immediately resend the 
command header with P3 = Luicc 

or 

b) status indicating a warning or error condition (but not SWl SW2 = '90 00'). 
1 If the UICC receives a case 2 command header and Le = Luicc, it shall return: 

a) data of length Le (= Luicc) under the control of the INS, INS, or '60' procedure bytes followed by the 
associated status 

or 

b) procedure bytes '61xx' instructing the Transport Layer of the Terminal to issue a GET RESPONSE 
command with a maximum length of 'xx', 'xx' being less than Luicc (this could happen if the card buffer 
size is smaller than Luicc) 

or 

c) status indicating a warning or error condition (but not SWl SW2 = '90 00'). 
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2 If the UICC receives a case 2 command header and Le < Luicc it shall return: 

a) data of length Le under the control of the INS, INS, or '60' procedure bytes followed by procedure bytes 
'61xx' instructing the Transport Layer of the Terminal to issue a GET RESPONSE command with a 
maximum length of 'xx' 

or 

b) status indicating a warning or error condition (but not SWl SW2 = '90 00'). 

7.3.1.1.5.2 Case 4 Commands 

If the UICC receives a case 4 command, after processing the data sent with the C-APDU, it shall return : 

a) procedure bytes '61 xx' instructing the Transport Layer of the Terminal to issue a GET RESPONSE 
command with a maximum length of 'xx' 

or 

b) status indicating a warning or error condition (but not SWl SW2 = '90 00'). 

The GET RESPONSE command so issued is then treated as described for case 2 commands. 

7.3.2 Transportation of a APDU using T=1 

A C-APDU is sent from the Application Layer of the Terminal to the Transport Layer of the Terminal. The Transport 
Layer maps the C-APDU onto the INF of an I-block without change. The I-block is sent to the UICC. The Response 
data (if present) and the status is returned from the UICC to the Transport Layer of the Terminal in the INF of an I- 
block. If the UICC returns a status which indicates: 

normal processing ('61XX'); 

a warning ('62XX' or '63XX'); 

an application condition ('9XXX'); 

or a successful execution of the command ('9000'); 

then it shall also return data (if available) associated with the processing of the command. No data shall be returned with 
any other status. 

The contents of the INF of the I-block are mapped onto the R-APDU without change and returned to the Application 
Layer of the Terminal. The transportation of APDU messages with T=l is mapped to the information of an I-block 
according to the four different cases described below. Each case is described in detail in the following subclauses. 

7.3.2.1 Case 1 

C-APDU is mapped to the INF of the I-block without any changes: 



Application Layer (C-APDU) 
Transport Layer (C-TPDU, INF) 

Transport Layer (R-TPDU, INF) 
Application Layer (R-APDU) 



Terminal 


^ 
<- 


UICC 


CLA INS PI P2 




CLA INS P1 P2 


Command Processing 






SW1||SW2 


SW1||SW2 


SW1||SW2 





Figure 7.10 

The response received from the INF in the I-block is mapped unchanged to the R-APDU. 
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7.3.2.2 Case 2 

The C-APDU is mapped to the INF of an I-block without any changes. 



Application Layer (C-APDU) 
Transport Layer (C-TPDU, INF) 



Terminal 


^ 
<- 


UICC 


CLA INS P1 P2 Le 




CLA INS P1 P2 Le 


Command Processing 






DATA||SW1||SW2 


DATA||SW1||SW2 


DATA||SW1||SW2 




Figure 7.11 





Transport Layer (R-TPDU, INF) 
Application Layer (R-APDU) 



The R-APDU consists of either the INF of the I-block or the concatenation of the INF of successive I-blocks all 
received in the same response, which all shall be chained. 



7.3.2.3 



Case 3 



The C-APDU is mapped without any changes to either an INF or is concatenated onto several successive I-blocks, 
which all shall be chained. 



Application Layer (C-APDU) 
Transport Layer (C-TPDU, INF) 

Transport Layer (R-TPDU, INF) 
Application Layer (R-APDU) 

Figure 7.12 

The INF of the I-block is mapped to the R-APDU without any changes. 

7.3.2.4 Case 4 

The C-APDU is mapped without any changes to either an INF or is concatenated onto several successive I-blocks, 
which all shall be chained. 
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Transport Layer (R-TPDU, INF) 
Application Layer (R-APDU) 
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CLA INS PI P2 Lc [Lc bytes of 
DATA] Le 
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Command Processing 



Le byte of DATA||SW1 ||SW2 



Figure 7.13 

The response consists of either the INF of an I-block received in the response or the concatenation of INF of successive 
I-blocks in response, which all shall be chained. 



7.4 Application Layer 



The application protocol consists of an ordered set of exchanges between the Application Layer and the Transport Layer 
of the Terminal. Application protocols are defined in subsequent parts of this specification. 

Each step in an application layer exchange consists of a command-response pair, where the Application Layer of the 
Terminal sends a command to the UICC via the Transport Layer of the Terminal, and the UICC processes it and sends a 
response to Application Layer of Terminal using the Transport Layer of the UICC and the Transport Layer of Terminal. 
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Each specific command (C-APDU) has a specific response (R-APDU). The commands and responses are called 
command messages and response messages. The structure of the C-APDU can be found in clause 10.2. The structure of 
the R-APDU can be found in clause 10.3. 

Both command and response messages may contain data. Thus, four cases shall be managed by the transmission 
protocols via the transport layer, as shown in table 7. 11. 

Table 7.11 : Definition of Cases for Data in APDUs 



Case 


Command Data 


Response Data 


1 


Absent 


Absent 


2 


Absent 


Present 


3 


Present 


Absent 


4 


Present 


Present 



7.4.1 Exchange of APDUs 

The following figure shows the principle exchange of command/response pairs. 



Terminal 



C-APDU 



C-APDU 



■¥ 
<- 
^ 
<- 



UICC 



R-APDU 



R-APDU 



7.4.2 USAT Layer 



Figure 7.14 



The USAT layer uses application status words to indicate: 

the availability of a proactive command for the Terminal ('91XX'); 

the usage of response data to an Envelope command by the Terminal (nominal '9000', warning '62XX' or 
'63XX'); 

the temporary unavailability of the USAT to handle an Envelope command ('9300'), see subclause 11.6.6. 



7.4.2.1 



Proactive Command 



Where the status word SW1-SW2 is equal to '9000', the card can reply '91XX' to indicate that a proactive command is 
pending. The terminal uses the FETCH C-APDU to get the pending Proactive Command. The terminal sends to the 
UICC the response of the Proactive Command execution with the TERMINAL RESPONSE C-APDU. 

The mechanism, described hereafter for a case 4 C-APDU, is independent from the transport protocol. 
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C-APDU 

R-APDU 

Any C-APDU/R-APDU 

C-APDU = FETCH 

R-APDU 

Any C-APDU/R-APDU 

C-APDU = 

TERMINAL RESPONSE 

R-APDU 



Terminal 




UICC 


CLA INS PI P2 Lc [Lc DATA] Le 


^ 


Command Processing 


Luicc DATA||SW1='91'||SW2='XX' 


<- 


Luicc DATA||SW1='91'||SW2='XX' 








CLAINS='12'P1 P2Le='XX' 


^ 


Command Processing 


Le DATA=Proactive Command 
||SW1='90'||SW2='00' 


<- 


Le DATA=Proactive Command 
||SW1='90'||SW2='00' 








CLA INS='14' P1 P2 Lc [Lc DATA] 


^ 


Command Processing 


SW1||SW2 


<- 


SW1||SW2' 



7.4.2.2 



ENVELOPE Commands 



The ENVELOPE C-APDU is used to transmit data to the USAT. For some BER-TLV (e.g. SMS-PP Data Download) 
contained in the body of this command, the card may send back data to be transmitted by the Terminal on the 
acknowledgement channel (e.g. RP-ACK) or on the error channel (e.g. RP-ERROR). The BER-TLV objects are defined 
inTS3Llll[4]. 

This command is case 4 and is described here after for the two options. 

Case 4 : positive acknowledgement 



C-APDU = ENVELOPE 
R-APDU 
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<- 


Luicc DATA||SW1='90'||SW2='00' 



The Terminal shall consider the data field received as a positive acknowledgement and use the normal 
acknowledgement channel (e.g. RP-ACK) when the Status Word present in the R-APDU is '9000'. 

Case 4 : negative acknowledgement 



C-APDU = ENVELOPE 
R-APDU 



Terminal 




UICC 


CLA INS='C2' P1 P2 
Lc [Lc DATA] Le=00 


^ 


Command Processing 


Luicc DATA 
||SW1='62'or'63'||SW2='XX' 


<- 


Luicc DATA 
||SW1='62'or'63'||SW2='XX' 



The Terminal shall consider the data field received as a negative acknowledgement and use the error acknowledgement 
channel (e.g. RP-ERROR), when the Status Word present in the R-APDU is either '62XX' or '63XX'. 



8 Application and File structure 

This clause describes the application and logical structure for the UICC. 

8.1 UICC Application structure 

An example of organisation of applications in the UICC is listed in figure 8.1. 
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EF4 



EF5 



Figure 8.1 : Example of an application structure 

The present document does not impose any restrictions on the location of applications. All applications are uniquely 
identified by application identifiers that are obtained from EFdir. These application identifiers are used to select the 
application. 

EFdir, EFpl and EFiccid are all mandatory and reside directly under the Master File. See clause 13 of the present 
document for details. 

DFtelecomIS optional. If present it resides under the MF and use the reserved FID '7F 10'. DFtelecom contains 
application independent information. 

8.2 File types 

This subclause defines the file types that applies to applications complying to this standard. 

8.2.1 Dedicated files 

A Dedicated File (DF) allows for a functional grouping of files. It can be the parent of DFs and/or EFs. DFs are 
referenced by file identifiers. 

An Application DF (ADF) is a particular DF that contains all the DFs and EFs of an application. 



8.2.2 Elementary files 



8.2.2.1 



Transparent EF 



An EF with a transparent structure consists of a sequence of bytes. When reading or updating, the sequence of bytes to 
be acted upon is referenced by a relative address (offset), which indicates the start position (in bytes), and the number of 
bytes to be read or updated. The first byte of a transparent EF has the relative address '00 00'. The total data length is 
indicated in the SELECT response of the EF. 
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8.2.2.2 



Linear fixed EF 



An EF with linear fixed structure consists of a sequence of records all having the same (fixed) length. The first record is 
record number 1 . The length of a record as well as this value multiplied by the number of records are indicated in the 
SELECT response of the EF. 





Record 1 


Record 2 




Record n 



Figure 8.2: Structure of a linear fixed file 

There are several methods to access records within an EF of this type: 

absolutely using the record number; 

when the record pointer is not set it shall be possible to perform an action on the first or the last record by using 
the NEXT or PREVIOUS mode; 

when the record pointer is set it shall be possible to perform an action on this record, the next record (unless the 
record pointer is set to the last record) or the previous record (unless the record pointer is set to the first record); 

- by identifying a record using pattern search. 

If an action following selection of a record is aborted (e.g. due to an unsuccessful execution of a command), then the 
record pointer shall remain set at the record at which it was set prior to the action. 

It is not possible, at present, to have more than 254 records in a file of this type, and each record cannot be greater than 
255 bytes. 



8.2.2.3 



Cyclic EF 



Cyclic files are used for storing records in chronological order. When all records have been used for storage, then the 
next storage of data shall overwrite the oldest information. 

An EF with a cyclic structure consists of a fixed number of records with the same (fixed) length. In this file structure 
there is a link between the last record (n) and the first record. When the record pointer is set to the last record n, then the 
next record is record 1. Similarly, when the record pointer is set to record 1, then the previous record is record n. The 
last updated record containing the newest data is record number 1, and the oldest data is held in record number n. 





Record 1 


Record 2 




Record n 



Figure 8.3: Structure of a cyclic file 

For update operations only PREVIOUS record shall be used. For reading operations, the methods of addressing are 
Next, Previous, Current and Record Number. 

If an action following selection of a record is aborted (e.g. due to an unsuccessful execution of a command), then the 
record pointer shall remain set at the record at which it was set prior to the action. 
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It is not possible, at present, to have more than 254 records in a file of this type, and each record cannot be greater than 

254 bytes. 



8.3 File referencing 



A File IDentifier (FID) is used to address or identify a specific file. The FID consists of two bytes and shall be coded in 
hexadecimal notation. 

FIDs shall be subject to the following conditions: 

the FID shall be assigned at the time of creation of the file concerned; 

no two files under the same parent shall have the same ID; 

the immediate children of the current DF, the parent DF or the immediate children of the parent DF shall not 

have the same FID. 

A path is a concatenation of FIDs. The path starts from MF or the current DF, and ends with the identifier of the file 
itself. If the identifier of the current DF is unknown, the reserved value '3FFF' shall be used at the beginning of the path. 
The order of the FIDs is always in the direction from father to child. 

A short file identifier (SFI) is coded as 5 bits valued in the range from 1 to 30. No two files under the same parent shall 
have the same SFI. 

A DF name is coded on 1 to 16 bytes. The DF name is the AID and shall be unique within a card. 



8.4 IVIethods for selecting a file 



After the UICC activation (as defined in clause 6.1) and the Answer To Reset (ATR), the Master File (MF) is implicitly 
selected and becomes the Current Directory. Each file may then be selected by using the SELECT function, using one 
of the 3 file referencing methods defined in this subclause. 

8.4.1 SELECT by File Identifier Referencing 

Selecting a DF, an ADF or the MF sets the Current Directory. After such a selection there is no current EF. Selecting an 
EF sets the current EF and the Current Directory remains the DF, ADF or MF, which is the parent of this EF. The 
current EF is always a child of the Current Directory. Only the ADF of the current application can be selected by FID. 

Any application specific command shall only be operable if it is specific to the Current Directory. 

The following files may be selected, by File IDentifier (FID) referencing, from the last selected file: 

any file which is an immediate child of the Current Directory; 
any DF which is an immediate child of the parent of the current DF; 
the parent of the Current Directory; 
the current DF or ADF; 
- the MF. 

Figure 8.4 is an example of the logical structure for an application conforming to this document. 
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Figure 8.4: Example of a logical structure 

The following table gives the valid selections for an application complying to this document for the logical structure in 
figure 8.4, if the FID is used. Reselection of the last selected file is also allowed but not shown. 

Table 8.1 : File selection 



Last selected file 


Valid Selections 


MF 


DF1, EF1, EF-DIR 


DF1 


MF, EF2, 


ADF1 


MF, DF3, DF4, EF3 


DF3 


MF, ADF1, DF4, DF5, EF4 


DF4 


MF, ADF1, DF3, EF5, EF6 


DF5 


MF, DF3, EF7 


EF1 


MF, DF1, EF-DIR 


EF2 


MF, DF1 


EF3 


MF, ADF1, DF3, DF4 


EF4 


MF, ADF1, DF3, DF5, 


EF5 


MF, DF4, ADF1, EF6 


EF6 


MF, DF4, ADF1, EF5 


EF7 


MF, DF3, DF5 



8.4.2 SELECT by Path Referencing 



A file, DP or EF, may be referenced by path, as defined in clause 8.3. Table 8.2 contains examples of selection by path 
from figure 8.6. In this example, it is considered that the current application (ADFl) has been previously selected by DF 
name. The FID of ADFl is noted '7FFF' (see clause 8.5) in the table. 
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Table 8.2: Examples of file selection by path 



Last selected DF 


Beginning of the path 


Example Selections 


any 


MF 


'EF1', 'EF-DIR', 'DF1', 'DF1||EF2' 


any 


any 


7FFF||DF3', '7FFF||DF3||EF4', 
7FFF||DF3||DF5', 7FFF||DF3||DF5||EF7' 
7FFF||DF4', 7FFF ||DF4||EF5', 
7FFF||DF4||EF6, 
7FFF||EF3' 


DF1 


Current DF 


'EF2' 


DF3 


Current DF 


'DF5', 'DF5||EF7', 'EF4' 


DF4 


Current DF 


'EF5', 'EF6' 


DF5 


Current DF 


'EF7' 



8.4.3 Short File Identifier 

Any EF within a DF can be implicitly selected without giving a SELECT command by applying one of the following 
commands at the DF or ADF level and giving a Short File Identifier (SFI) as a part of the command: 

- READ BINARY; 

- UPDATE BINARY; 

- READ RECORD; 

- UPDATE RECORD; 

- INCREASE; or 

- SEARCH RECORD. 

Support of SFI for a specific file is indicated if the FCI of the file contains a TLV DO with tag '88'. 

If the length is it indicates that the file does not support the SFI. 

TLV DO is absent indicates that the 5 least significant bits of the FID may be used as SFI. 

SFI cannot be used in a path or as a file identifier e.g. in SELECT command. 

When the READ RECORD command contains a valid SFI, it sets the file as the current EF and resets the current record 
pointer. Subsequent records are read with the READ RECORD command without SFI. 

When the UPDATE RECORD command contains a valid SFI, it sets the file as the current EF and resets the current 
record pointer. Subsequent records are updates with the UPDATE RECORD command without SFI. 

When the INCREASE command contains a valid SFI, it sets the file as the current EF and resets the current record 
pointer. Subsequent records are increased with the INCREASE command without SFI. 

When the SEARCH RECORD command contains a valid SFI, it sets the file as the current EF and resets the current 
record pointer. Subsequent records are searched with the SEARCH RECORD command without SFI. 



8.5 Application characteristics 



An application may be either explicitly or implicitly referenced. 

An application is activated by explicit selecting it with the AID. This sets the application's ADF as the current ADF. 

A current ADF can be referenced by FID with the implicit reference value '7F FF'. 
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8.5.1 Explicit Application selection 

8.5.1.1 SELECT by DF Name 

A selectable application, represented in the UICC by the AID, shall be referenced by a DF name coded on 1 to 16 bytes. 
Each name shall be unique within a UICC. A DF name can be used in the SELECT command to select a selectable 
application. 

8.5.1 .2 SELECT by partial DF Name 

Selection by partial DF Name is for further study within 3GPP TSG-T WG3. 



8.5.2 Application session activation 



The application session is initiated when the terminal sends a SELECT command , with the application's AID, 
indicating in the command parameters that the application shall be activated. 

An application may need an initialisation procedure to be performed after its activation. This procedure is outside the 
scope of the present document but shall be described in the application specification. The procedure is used to bring the 
terminal and the application in the UICC to a well defined state. 

The ME may send to the UICC a specific Status command indicating that the initialisation procedure of the application 
has been successfully executed. 

There can only be one active session on a given logical channel. 

8.5.3 Application session termination 

An application may have a session termination procedure to be performed before the application is terminated. This 
procedure shall be described in the application specification. Before this procedure is executed, the ME may send to the 
UICC a specific Status command indicating that the termination procedure of the application will start. After this 
termination procedure has been executed the terminal and the application are in a well defined state. 

An application session is then terminated if one of the following events occur on the same logical channel that the 
application session has been activated on: 

implicitly; if a SELECT by DFname command with an AID different from the currently active application is 
performed by the UICC, indicating in the command parameters that this new application shall be activated; 

explicitly; if the application is reselected using the SELECT by DF^ame command with the AID corresponding 
to the currently active application, and indicating in the command parameters that the application shall be closed; 

the terminal performs a reset of the UICC. 

8.5.4 Application session reset 

An application is reset if the application is reselected using the SELECT by DF^ame command with the AID 
corresponding to the currently active application, indicating in the command parameters that the application shall be 
activated. 

Reset initialises the application session activation procedure. The security status of the application is updated according 
to the application's session activation procedure, as specified by the application. 

8.5.5 GSM/USIM application interaction and restrictions 

Activation of a USIM session excludes the activation of a GSM session. In particular, this implies that once a USIM 
application session has been activated, commands sent to the UICC with CLAss byte set to 'AO' shall return SW1SW2 
'6E 00' (class not supported) to the terminal. 
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Similarly, activation of a GSM session excludes the activation of a USIM session. 
At most one USIM session can be active at the same time. 

8.6 Reservation of file IDs 

The following FIDs are reserved by the present document: 

ADF: 

operational use: 
7F FF' 

Dedicated Files: 

administrative use: 

7F 4X', '5F1X', '5F2X'. 
operational use: 

7F 10' (DFtelecom), 7F 20' (DFgsm), 7F 21' (DFdcsisoo), 7F 22' (DFis_4i), 7F 23' (DFfp_cts), 7F24' 
(DFtia/eia-136), '7F25' (DFtia/eia-95') and '7F 2X', where X ranges from '6' to 'F'. 
NOTE: '7F80' (DFpoc) is used for the Japanese PDC specification. 
'7F 90' (DFtetra) is used for the TETRA specification. 

- reserved under '7F10': 

'5F50' (DFgraphics); '5F 3A' (DFphonebook)- 

Elementary files: 
administrative use: 

'6F XX' in the DFs 7F 4X'; '4F XX' in the DFs '5F IX', '5F2X'. 

'6F IX' in the DFs '7F 10', '7F 20', '7F 21'; 

'4F IX' in all 2"'' level DFs. 

'2F EX' in the MF '3F 00'; 
operational use: 

'6F 2X', '6F 3X', '6F 4X' in 7F 10' and 7F 2X'; 

'4F YX', where Y ranges from '2' to 'F' in all 2"'' level DFs. 

'2F05', '2F06' and '2F IX' in the MF '3F 00'. 

- operational use ISO/lEC 7816-4 [13]: 

'2F00' EFdir, '2F01' EFatr in the MF '3F00'. 

In all the above, X ranges, unless otherwise stated, from '0' to 'F'. 



Security features 



Every application that conforms to this document may define security features in addition to the mandatory features 
defined in this clause. 



9.1 Supported security features 



A terminal that confirms to the present document and is designed for a multi-application UICC shall recognise the 
security attribute tags specified in the present document. 

A single application terminal conforming to the present document shall support one of the access rules format specified 
in the present document. The application specifies which format is used. 

A multi-application capability terminal that is designed to support a multi-application UICC shall support the usage of 
the level 1 verification requirements (PIN) and the level 2 verification requirements (PIN2). The coding is defined in 
table 9.3. The terminal shall, in addition, support the usage of a universal PIN as defined in the present document. 

A multi-application capability UICC conforming to the present document shall support more than one level 1 user 
verification requirement (PIN). The specific key reference for the level 1 PIN is specified by the application in 
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accordance with table 9.3. In addition, the application may specify a level 2 user verification requirement (PIN2). A 
multi-application capability UICC shall support the use of a universal PIN. A multi-application capability UICC shall 
support access rules defined in security attributes indicated in tag '8B' (i.e. referenced to expanded format). 

A single application UICC shall support one level 1 user verification requirement (PIN) as defined in table 9.3. In 
addition the application may specify a level 2 user verification requirement as a second application verification 
requirement (PIN2). A single application UICC may contain one or more selectable applications if there are no security 
aspects to be considered between the different selectable applications. From the security point of view only one level 1 
verification requirement (PIN) is assigned to all ADFs/DFs and files on the UICC. In addition, a level 2 user 
verification requirement (PIN2) may be assigned on the application level. From the security and access rules point of 
view the UICC is seen as a single application card. The coding of the level 1 and level 2 user verification requirement 
shall be according to table 9.3. 



9.2 Security architecture 



An application on a UICC conforming to the present document shall specify a level 1 key reference as the user 
verification (PIN). In addition the application may specify a level 2 key reference as a second user verification 
requirement (PIN2). The coding of the level 1 and level 2 user verification requirement shall be according to table 9.3. 
In addition, an application may specify the usage of a universal PIN as a replacement for the application PIN. 

In order to perform commands other than SELECT and STATUS the security condition for the file must be met. A 
security condition data object contains the conditions to be met in order to perform certain commands on a selected 
DF/EF. 

The security architecture consists of the following parts: 

Security attributes; a set of access rules. 

Access rules; consist of an access mode and one or more security conditions. 

Access Mode (AM); indicates to which operations (commands) the security condition applies. 

Security Condition (SC); contains references to the applicable key references (PINs). 
The following sub-clauses define the parts constituting the security architecture. 

9.2.1 Security attributes 

The security attributes are attached to a DF/EF and they are part of the FCP. The security attributes are indicated in the 
FCP using tag '8B', tag '8C' or tag 'AB' depending upon the format used, see ISO/IEC 7816-9 [17]. 

9.2.2 Access mode 

The access mode byte/data object (AM byte/AM_DO) defines for which group/type of command(s) the security 
condition apply. The interpretation of the AM byte/AM_DO is file dependent (i.e. different for a DF and an EF), see 
ISO/IEC 7816-9 [17]. The command type/group is defined and coded according to ISO/IEC 7816-9 [17]. 

For instructions not belonging to a group as defined in ISO/IEC 7816-9 [17] the access rights can be indicated using 
AM_DO tags '81' - '8F'. The value of the tag defining the AM_DO indicates what description of the command exists in 
the definition list to follow in the value part of the data object. The coding of bit b4 - b 1 in the AM_DO tag is defined 
in ISO/IEC 7816-9 [17]. 

The security conditions for bits not set to '1' in the AM byte are set to NEVer by default. 



9.2.3 Security condition 



The Security Condition (SC) indicates which security related procedures (user PIN verification) shall be satisfied before 
a command may be performed on a file. The SC is coded according to ISO/IEC 7816-9 [17]. 
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9.2.4 Access rules 

The access rule defines the security conditions for access to a file for each command/command group indicated in the 
AM-byte/AM_DO. The security condition is indicated in the SC-byte(s)/SC_DO(s) following the AM-byte/AM_DO. 
The access rule is coded by using one ore more AM-bytes/AM_DOs each followed by one or more security conditions 
that are to be satisfied for the appropriate access. 

The access rules may be coded in a compact or an expanded format. Furthermore, it is possible to combine one or more 
SCs to one AM such that at least one SC (the OR relation) shall be fulfilled before the command can be executed. It is 
possible to combine the SC such that more than one SC has to be fulfilled (the AND relation). 

An access rule is a set of requirement(s) that shall be met in order to perform operations on a file. An access rule 
contains one or more security attributes, the AM byte/AM_DO in the attribute indicates what commands can be 
performed and the SC byte/SC_DO indicates what SC shall be met to be able to perform the commands indicated in the 
AM byte/AM_DO. 

The CRT tags for SC_DOs are defined in ISO/IEC 7816-9 [17]. The SC required to perform commands indicated in the 
AM byte/ AM_DO may be a simple condition or a logical OR or AND condition of several SC_DOs. The constructed 
TLV object containing AM bytes/ AM_DOs and SC bytes/SC_DOs is an access rule. An access rule can be indicated in 
the FCP in one of the following ways: 

Tag'SC Security attributes, compact format; 

Tag'AB' Security attributes expanded format; 

Tag'SB' Security attributes. Referenced to expanded format. 

9.2.5 Compact format 

The compact format is indicated by tag '8C' in the FCP. In the compact format an access rule consists of an AM byte 
and one or more SC bytes as defined in ISO/IEC 7816-9 [17]. 

The AM byte conveys two types of information. The interpretation of the AM byte itself (coded on b8), and the number 
of SC bytes following, this is equal to the number of bits set to '1' in bits b7-bl in the AM byte. If b8 in the AM byte is 
set to '0' the interpretation of bits b7-bl is as defined in ISO/IEC 7816-9 [17]. If b8 in the AM byte is set to T the usage 
of bits b7-b4 is proprietary. 

When multiple sets of an AM byte and one or more corresponding SC bytes are present in the value field they present 
an OR condition. 



Example 1: 



The access rule for READ always for an EF is coded using the compact format as follows: 



Tag 


L 


AM 


SC 


'8C' 


'02' 


'01' 


'00' 



Example 2: 



The access rule for UPDATE user PIN verification and READ always for an EF is coded using the 
compact format as follows: 



Tag 


L 


AM 


SC 


SC 


■8C' 


'03' 


'03' 


'10' 


'00' 



9.2.6 Expanded format 

The expanded format is indicated by tag 'AB' in the FCP. This tag indicates a constructed data object. In the expanded 
format an access rule consists of one AM_DO followed by a sequence of SC_DOs. The contents of the AM_DO is 
defined by the tag that it is indicated with, see ISO/IEC 7816-9 [17]. Tag '80' indicates that the AM_DO contains an 
AM byte. The sequence of SC_DOs following the AM-DO is relevant for all commands specified in the AM_DO. The 
different SC_DOs can form an OR or an AND condition as defined in ISO/IEC 7816-9 [17]. The information following 
tag 'AB' in the FCP can contain a lot of data if the rule is complex. This information is part of the FCP that is 
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transmitted over the interface in the response to a SELECT or a STATUS command. The structure of the security 
attribute in expanded format is as follows: 



Tag 


length 


AM DO tag 


AM DO 


SC DO tag 


SC DO 


AM DO tag 


AM DO 


SC DO tag 


SC DO 


'AB' 




See ISO/I EC 
7816-9 




See ISO/IEC 
7816-9 




See ISO/IEC 
7816-9 




See ISO/IEC 
7816-9 





An example using the expanded format coding is given in Annex E. 

9.2.7 Access rule referencing 

Access rules may be shared between files in the UICC by referencing. This is accomplished by storing the security 
attributes in the expanded format in a linear variable/fixed file, the Access Rule Reference, EFarr, in the UICC. The 
structure of the EFarr file is as follows: 



Record Number (ARR) 


Record Content (Access Rule) 


'01' 


AM DOlISC DOilISC DO2I 1 AM DOl 1 SC DO3I 1 SC DO4 .... 


'02' 


AM DOlISC DOillAM D0| 1 SC DO5I 1 SC DOe .... 



The referenced format is indicated in the FCP following tag '8B'. The access rule is stored in a file, EFarr. This file is a 
linear fixed/variable file. Referencing is based on the following two methods: 

- File ID and record number (File ID, Record number). 

File ID, SE ID and record number (File ID, SE ID, Record number). 

The second possibility allows the usage of different access rules in different security environments. 

Referencing EFarr is based on the file ID. This implies that an EFarr exists under each DF. If a file with the file ID 
indicated in tag '8B'an can not be found in the current DF the parent DF shall be used for searching for EFarr. The 
structure of the access rule referencing DO is as follows: 



Tag 


Length 


Value 


'8B' 


'03' 


File ID, record number 


'88' 


'02' -1- n X '02' 


File ID, SE IDni, Record number X, SE IDn2, Record number Y, 



Each record in EFarr contains a sequence of AM_DOs followed by SC_DOs. The content of the record is the rule that 
applies for access to the selected file. The content of a sample EFarr file is given in Annex F. 



9.3 Security Environment 



The security environment is a mechanism to specify for the card system the security functions that are available to 
provide protection to commands for a specific application of the card according to ISO/IEC 7816-8 [16]. In the 
referenced format it is possible to indicate different access rules as a function of the SE that is in use. 



9.3.1 Definition of tine Security Environment 

In case the referenced format contains SEID as the referencing method the terminal shall evaluate the SEID and 
perform the appropriate user verification accordingly. 

The following properties are mapped to SEOl (default SE) and SEOO (no authentication method required) for Release 
'99 (Card implementation): 



SEID 



'00' 



'01' 



Properties 



The global Application PIN disabled (the Universal PIN is either disabled or not known) 
The current global Application PIN is enabled or the Universal PIN is enabled but it is not to 
be used for verification and the global Application PIN is disabled 
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The above requirements are derived from table 9. 1 . A multi-application capability UICC shall support the use of SEOO 
and SEOl in order to allow application verification requirement to be replaced by the Universal PIN. A multi- 
application capability terminal shall support SEID referencing in EFarr. 

Table 9.1 : PIN mapping into SE 









Universal PIN status 


PIN to verify 


E 


NE 


APPL_PIN status 


E 


APPL PIN 
SEOl 


APPL PIN 
SEOl 


NE 


UUP 


Universal PIN 
SEOO 


NO PIN 
SEOO 


DUUP 


NO PIN 
SEOl 


NO PIN 
SEOO 


Key: UUP: Use Universal PIN 

DUUP: Don't Use Universal PIN 



9.4 



PIN definitions 



The following sub-clauses define the types of PIN that shall exist on a UICC, namely the Universal PIN and the 
application PIN, as well as other types of access conditions needed by the UlCC/an application. 



9.4.1 



Universal PIN 



A Universal PIN is a PIN that is used in a multi-application environment to allow several applications to share one 
common PIN. The Universal PIN is a global access condition that has been assigned a key reference value '11'. This key 
reference value shall not be used for anything else but to indicate the Universal PIN. 

In order to give access to several applications on a multi-appplication UICC, a terminal conforming to the present 
document shall support the usage of the Universal PIN. A multi-application UICC according to the present document 
shall support the usage of a Universal PIN. 

The Universal PIN shall be part of the access condition for each UICC application on a multi-application UICC that 
complies to the present document. In case of a single application capability UICC the Universal PIN shall not be used. 



9.4.2 Application PIN 



An Application PIN is a PIN that uses a global key reference (defined as level 1 in table 9.2) as defined in table 9.3. The 
Application PIN allows access to any file on the UICC where it is referenced in the access rules, i.e. this PIN has global 
access rights with respect to files. It becomes an application PIN based on where it is assigned. An application, from the 
security context point of view, may consist of one ore more ADFs/DFs. In this case the ADFs/DFs are seen as one 
application from the security and access rules point of view. All operations performed on a PIN (enable/disable/replace) 
covering several ADFs/DFs affects the applications where the PIN is used and the access rules where the corresponding 
key reference is used. 

9.4.3 Local PIN 

A local PIN is a PIN that uses a local key reference it is only valid within the ADF/DF where it is indicated in the FCP. 
A local PIN is defined as level 2 in table 9.2 and coded as defined in table 9.3. A local PIN referenced in an ADF or a 
DF, which is not DFTelecom, does not give access to DFtelecom. 
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9.5 PIN and key reference relation ship 

This subclause describes the relationship between the user verification requirement (PIN) and referencing to a PIN in 
the VERIFY, CHANGE, DISABLE/ENABLE VERIFICATION and UNBLOCK commands. 

9.5.1 Access condition mapping 

Access condition mapping, using SC_DOs, is done using the expanded format with the entries coded as CRT values, i.e. 
tag 'A4' is used. The CRT is a constructed TLV DO containing a usage qualifier TLV DO (tag '95') and a Key reference 
TLV DO (tag '83'). 

The access condition groups are defined according to table 9.2. Each group is divided into several key references. The 
usage of a key reference shall be in accordance with the group definition in table 9.2. 

Table 9.2: Access condition level coding 



Level 


Access Condition 




1 

2 
3to4 
5 to 6 

7 


ALWays 

User Verification (PIN) 

see NOTE 1 

Reserved for Future Use 

see NOTE 2 

NEVer 


NOTE 1 : Tliis level is reserved for a second level of user verification 
(PIN2) that may be defined by an application. 

NOTE 2: Allocation of these levels and the respective requirements for 
their fulfilment are the responsibility of the appropriate 
administrative authority. 



The levels indicated in table 9.2 are used in this document to refer to a specific group of access conditions. 

A key reference shall only be assigned for the purpose as it is defined in table 9.3. e.g., a level 1 key reference is always 
to be used for an application or a set of applications that share the same access conditions. A level 2 key reference is 
only valid within the ADF/DF where it is indicated. 
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Table 9.3: PIN mapping into key references 



CRT 
Tag 


Len 


Value 


Access Condition 


Level 


Key Ref 
Tag 


Len 


Value 


Usage 

Qualifier 

Tag 


Len 


Val 


'90' 


'00' 


- 


- 


- 


- 


- 


- 


ALW 





'A4' 
'A4' 
'A4' 
'A4' 


'06' 
'06' 
'06' 
'06' 


'83' 
'83' 
'83' 
'83' 


'01 
'01 
'01 
'01 




'01' 
'02' 
'03' 
'04' 


'95' 
'95' 
'95' 
'95' 


'01 
'01 
'01 
'01 




'08' 
'08' 
'08' 
'08' 


PIN AppI 1 
PIN AppI 2 
PIN AppI 3 
PIN AppI 4 


1 


'A4' 
'A4' 
'A4' 
'A4' 
'XX' 


'06' 
'06' 
'06' 
'06' 
'06' 


'83' 
'83' 
'83' 
'83' 
'83' 


'01 
'01 
'01 
'01 
'01 




'05' 
'06' 
'07' 
'08' 
'09' 


'95' 
'95' 
'95' 
'95' 
'95' 


'01 
'01 
'01 
'01 
'01 




'08' 
'08' 
'08' 
'08' 
'08' 


PIN AppI 5 
PIN AppI 6 
PIN AppI 7 
PIN AppI 8 
RFU 


1 


'A4' 
'A4' 
'A4' 
'A4' 
'A4' 


'06' 
'06' 
'06' 
'06' 
'06' 


'83' 
'83' 
'83' 
'83' 
'83' 


'01 
'01 
'01 
'01 
'01 




'OA' 
'OB' 
'OC 
'OD' 
'OE' 


'95' 
'95' 
'95' 
'95' 
'95' 


'01 
'01 
'01 
'01 
'01 




'08' 
'08' 
'08' 
'08' 
'08' 


ADM1 
ADM2 
ADM3 
ADM4 
ADM5 


5 


'A4' 


'06' 


'83' 


'01 




'11' 


'95' 


'01 




'08' 


PIN Universal PIN 


1 


'XX' 


'06' 


'83' 


'01 




'12-1E' 


'95' 


'01 




'08' 


RFU (Global) 


3 


'A4' 
'A4' 
'A4' 
'A4' 


'06' 
'06' 
'06' 
'06' 


'83' 
'83' 
'83' 
'83' 


'01 
'01 
'01 
'01 




'81' 
■82' 
'83' 
'84' 


'95' 
'95' 
'95' 
'95' 


'01 
'01 
'01 
'01 




'08' 
'08' 
'08' 
'08' 


Second PIN AppI 1 
Second PIN AppI 2 
Second PIN AppI 3 
Second PIN AppI 4 


2 


'A4' 
'A4' 
'A4' 
'A4' 
'A4' 


'06' 
'06' 
'06' 
'06' 
'06' 


'83' 
'83' 
'83' 
'83' 
'83' 


'01 
'01 
'01 
'01 
'01 




'85' 
'86' 
'87' 
'88' 
'89' 


'95' 
'95' 
'95' 
'95' 
'95' 


'01 
'01 
'01 
'01 
'01 




'08' 
'08' 
'08' 
'08' 
'08' 


Second PIN AppI 5 
Second PIN AppI 6 
Second PIN AppI 7 
Second PIN AppI 8 
RFU 


2 


'A4' 
'A4' 
'A4' 
'A4' 
'A4' 


'06' 
'06' 
'06' 
'06' 
'06' 


'83' 
'83' 
'83' 
'83' 
'83' 


'01 
'01 
'01 
'01 
'01 




■8A' 
'8B' 
'8C' 
'8D' 
'8E' 


'95' 
'95' 
'95' 
'95' 
'95' 


'01 
'01 
'01 
'01 
'01 




'08' 
'08' 
'08' 
'08' 
'08' 


ADM6 
ADM7 
ADM8 
ADM9 
ADM10 


6 


'XX' 


'06' 


'83' 


'01 




'90-9E' 


'95' 


'01 




'08' 


RFU (Local) 


4 


'97' 


'00' 


- 


- 


- 


- 


- 


- 


NEV 


7 


NOTE The CRT value 'XX' for RFU key references is specified at the time when the value is taken 
into use. 



A single application (from the security context point of view) capability UICC shall use key reference '01' as PIN and 
key reference '81' as PIN2. A multi-application capability UICC shall use one of the key references in the range of '01' 
to '08' as PIN and may use key references in the range from '81' to '88' as PIN2. In addition a multi-application 
capability UICC shall support the use of key reference '11' as a universal PIN, see subclause 9.3.1 for the definition of a 
universal PIN. Multi-applications (from the security context point of view) on a UICC shall not share any key 
references except for key reference '11', which is used as the universal PIN. 

9.5.2 PIN status indication 

The status of a PIN that is used by an application for user verification is stored in the PS Template DO and shall be 
indicated in the FCP in a response to the SELECT or STATUS command issued at the application/DF level. The PIN 
status information is indicated in the FCP in the PS template DO using tag 'C6'. The PS template DO conveys two types 
of data, first the PS_DO indicated by tag '90' that indicates the status of the PIN(s) enabled/disabled. The PS_DO is 
followed by one or more key reference data objects indicated by tag '83'. The PIN status may be encoded over several 
bytes. For each bit set to '1' the corresponding key reference (PIN) is enabled. The PS_DO is coded using a bitmap list. 
Bit b8 in the most significant byte corresponds to the first key reference indicated by tag'83' following the PS_DO. Bits 
b7-bl are mapped to consecutive key references indicated by tag '83'. A key reference data object may be preceded by a 
usage qualifier data object. The usage qualifier data object indicated by tag '95' indicates whether an enabled PIN needs 
to be verified for access. The usage qualifier is intended to be used only in conjunction with the universal PIN, see 
subclause 9.4.1. If the usage qualifier data object is empty or not present in conjunction with a key reference this 
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indicates that the key reference following the usage qualifier do not support this feature, and it shall always be verified 
if enabled. The content of the PS_DO usage qualifier is defined in table 9.4. From table 9.4, the value to be used for 
user PIN verification is '08'. 

Table 9.4: Usage qualifier coding for PS_DO 



b8 b7 b6 b5 b4 


b3 b2 b1 


Meaning 








the verification requirement is not used for 
verification 


1 . . . . 




- use verification (DST,CCT) 

- use encipherment (CI) 

- use external autlientication (AT) 


1 . . . 




- use computation (DST,CCT) 

- use decipherment (CI) 

- use internal authentication (AT) 


1 


. 


- use SIVI response (CCT, CT, DST) 


1 


. 


- use SM command (CCT, CT, DST) 


1 


- 


- use the PIN for verification (Key 
Reference data user knowledge based) 


. 


1 


-use user authentication, biometric based 





X X 


RFU (default = 00) 



The PS template DO is constructed as indicated in tables 9.5 and 9.6. 

Table 9.5: PS Template DO structure 



PS 

Template 

DO Tag 


L 


PS-DO 
Tag 


L 


V 
PS-byte(s) 


Key- 
reference 
tag 


L 


V 


Key- 
reference 
tag 


L 


V 


'C6' 




'90' 






'83' 


'01' 




'83' 


'01' 





Table 9.6: PS Template DO structure when PS_DO usage qualifier is used 



PS 

Template 

DO Tag 


L 


PS-DO 
Tag 


L 


V 
PS-byte(s) 


Usage 

Qualifier 

tag 


L 


V 


Key- 
reference 
tag 


L 


V 


Key- 
reference 
tag 


L 


V 


'C6' 




'90' 






'95' 


'01' 




'83' 


'01' 




'83' 


'01' 





1 Structure of commands and responses 

This clause defines the command and response APDUs supported by the UICC. 

1 0.1 Command APDU Structure 

This clause states a generic structure of an application protocol data unit - APDU - that is used by the application 
protocol on the top of the transmission protocol for sending a command to the card. 

A command APDU consists of a header and a body part. The contents of the command APDU are depicted in table 10. 1 
where the header consists of the CLA, INS, PI and P2 bytes that are mandatory for a command APDU and an optional 
body part that can contain the Lc, Data and Le. Parameters are further explained in the following subclauses. 
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Table 10.1 : Contents of Command APDU 



Code 


Length 


Description 


Grouping 


CLA 


1 


Class of instruction 


Header 


INS 


1 


Instruction code 


P1 


1 


Instruction parameter 1 


P2 


1 


Instruction parameter 2 


Lc 


Oor1 


Number of bytes in the command data field 


Body 


Data 


Lc 


Command data string 


Le 


Oor1 


IVIaximum number of data bytes expected in response of the command 



Four cases of C-APDU structure are possible as defined in table 10.2: 

Table 10.2: Cases of C-APDUs 



Case 


Structure 


1 


CLA INS P1 P2 


2 


CLA INS P1 P2 Le 


3 


CLA INS P1 P2 Lc Data 


4 


CLA INS P1 P2 Lc Data Le 



10.1.1 Coding of Class Byte 

The most significant nibble of the Class byte (b8-b5) codes the type of the command as stated in table 10.2. Bits b4 and 
b3 are used for indication of secure messaging format (see table 10.4). Bits b2 and bl indicates the logical channel used. 
Logical channels are numbered from to 3. If the card supports the logical channel mechanism, the maximum number 
of available logical channels is indicated in the card capabilities data object of historical bytes of an ATR (refer to 
ISO/IEC 7816-4 [13]). If the card capabilities data object is missing, logical channel b2=bl=0 is supported only. 

Table 10.3: Coding of Class Byte 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


Value 


IVIeaning 














- 


- 


- 


- 


'OX' 


The coding is according to 
ISO/IEC 7816-4 [131 


1 





1 





- 


- 


- 


- 


'AX' 


Coded as ISO/IEC 7816-4 [13] unless stated 
otherwise 


1 











- 


- 


- 


- 


'8X' 


Structured as ISO/IEC 7816-4 [13], coding 
and meaning is defined in this specification 


- 


- 


- 


- 


X 


X 


- 


- 


- 


Secure IVIessaging indication (see table 
10.4) 


- 


- 


- 


- 


- 


- 


X 


X 


- 


Logical channel number (see clause 10.3) 



Table 10.4: Coding of Security Messaging Indication 



b4 


b3 


Meaning 








No SM used between Terminal and card 





1 


Proprietary SIVI format 


1 


X 


Secure messaging according to ISO/IEC 7816-4 [13] used 


1 





Command header not authenticated 


1 


1 


Command header authenticated 



By default no secure messaging is supported by the card, i.e. b4=b3=0, unless it is stated otherwise by an application. 



1 0.1 .2 Coding of Instruction Byte 

Table 10.5 depicts coding of instruction byte of the commands. 
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Table 10.5: Coding of Instruction Byte of the Commands 
for a telecom application 



COMMAND 


CLA 


INS 


Command APDUs 






SELECT FILE 


OX 


'A4' 


STATUS 


8X 


'F2' 


READ BINARY 


OX 


'BO' 


UPDATE BINARY 


OX 


'D6' 


READ RECORD 


OX 


'B2' 


UPDATE RECORD 


OX 


'DC 


SEARCH RECORD 


OX 


'A2' 


INCREASE 


8X 


'32' 


VERIFY 


OX 


'20' 


CHANGE PIN 


OX 


'24' 


DISABLE PIN 


OX 


'26' 


ENABLE PIN 


ox 


'28' 


UNBLOCK PIN 


ox 


'2C' 


DEACTIVATE FILE 


ox 


'04' 


ACTIVATE FILE 


ox 


'44' 


AUTHENTICATE 


ox 


'88' 


TERMINAL PROFILE 


80 


'10' 


ENVELOPE 


80 


'C2' 


FETCH 


80 


'12' 


TERMINAL RESPONSE 


80 


'14' 


MANAGE CHANNEL 


OX 


'70' 


Transmission oriented APDUs 






GET RESPONSE 


OX 


'CO' 



1 0.1 .3 Coding of Parameter Bytes 

The value of the parameters PI and P2 depends on the command. If the parameter is not used, the value is set to '00'. 
Coding of the parameter bytes is presented in the command definition sections. 

10.1.4 Coding of Lc Byte 

The number of data bytes present in the data field of the command APDU is presented in the parameter Lc. Lc is 
optional, in the command APDU, however if the Lc is present in the command APDU, data field consists of the Lc 
subsequent bytes. The terminal may send from 1 to 255 bytes of command data. 

10.1.5 Coding of Data Part 

When present in a command or response APDU the structure of the data field is specific to each command. 

10.1.6 Coding of Le Byte 

The maximum number of bytes expected in the data part of the response APDU is presented in the parameter Le, which 
is optional meaning that if the Terminal does not expect any data in the response APDU Le is absent from the command 
APDU. However, if Le is present in the command APDU, the data field of the response APDU is expected to consist of 
the Le bytes. 

Le set to '00' indicates that the Terminal expects to receive at most the maximum number of bytes, i.e. 256, in the 
response ADPU. The UICC may return any number of bytes in the range 1 to 256. 
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1 0.2 Response APDU Structure 



The response APDU consists of an optional data field and a mandatory status part divided into two bytes; SWl and 
SW2. The number of bytes received in the response APDU is denoted Lr (length of the response data field). The 
structure of the response APDU is shown in table 10.6. 

Table 10.6: Contents of Response APDU 



Code 


Length 


Description 


Data 


Lr 


Response data string 


SWl 


1 


Status byte 1 


SW2 


1 


Status byte 2 



Coding of SWl and SW2 is presented in 10.2.1. 

10.2.1 Status Conditions Returned by tine UICC 

Status of the card after processing of the command is coded in the status bytes SWl and SW2. This subclause specifies 
the coding of the status bytes. 



10.2.1.1 



Normal processing 

Table 10.7: Status byte coding - normal processing 



SWl 


SW2 


Description 


'90' 


'00' 


- Normal ending of the command 


'91' 


'XX' 


- Normal ending of the command, with extra information from the 
proactive UICC containing a command for the Terminal. Length 'XX' 
of the response data 



10.2.1.2 Postponed processing 



Table 10.8: Status byte coding - postponed processing 



SWl 


SW2 


Error description 


'93' 


'00' 


- SIM Application Toolkit is busy. Command cannot be executed at 
present, further normal commands are allowed. 
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10.2.1.3 Warnings 



Table 10.9: Status byte coding - warnings 



SW1 


SW2 


Description 


'62' 


'00' 


- No information given, state of non volatile memory unchanged 


'62' 


'81' 


- Part of returned data may be corrupted 


'62' 


'82' 


- End of file/record reached before reading Le bytes 


'62' 


'83' 


- Selected file invalidated 


'62' 


'84' 


- FCI not formatted according to subclause 11.1.1 .3.1 


'63' 


'00' 


- No information given, state of non volatile memory changed 


'63' 


'81' 


- File filled up by the last write 


'63' 


'CX' 


- Command successful but after using an internal update retry routine 
'X' times 

- Verification failed, 'X' retries remaining (see note) 


NOTE; For the VERIFY PIN command, SW1 SW2 indicates that the command was 
successful but the PIN was not correct and there are 'X' retries left. For all 
other commands it indicates the number of internal retries performed by the 
card to complete the command. 



10.2.1.4 Execution errors 

Table 10.10: Status byte coding - execution errors 



swi 


SW2 


Description 


'64' 


'00' 


No information given, state of non-volatile memory unchanged 


'65' 


'00' 


No information given, state of non-volatile memory changed 


'65' 


'81' 


Memory problem 



10.2.1.5 Checking errors 



Table 10.11 : Status byte coding - checking errors 



swi 


SW2 


Description 


'67' 


'XX' 


- Wrong length (see note) 


'6B' 


'00' 


- Wrong parameter(s) P1-P2 


'6D' 


'00' 


- Instruction code not supported or invalid 


'6E' 


'00' 


- Class not supported 


'6F' 


'XX' 


- Technical problem, no precise diagnosis 


NOTE: the interpretation of this status word is command dependent 



10.2.1.5.1 Functions in CLA not supported 

Table 10.12: Status byte coding - functions in CLA not supported 



SWI 


SW2 


Description 


'68' 


'00' 


No information given 


'68' 


'81' 


- Logical channel not supported 


'68' 


'82' 


- Secure messaging not supported 
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10.2.1.5.2 Command not allowed 

Table 10.13: Status byte coding - command not allowed 



SW1 


SW2 


Description 


'69' 


'00' 


No information given 


'69' 


'81' 


- Command incompatible with file structure 


'69' 


'82' 


- Security status not satisfied 


'69' 


'83' 


- Authentication/PIN method blocked 


'69' 


'84' 


- Referenced data invalidated 


'69' 


'85' 


- Conditions of used not satisfied 


'69' 


'86' 


- Command not allowed (no EF selected) 



10.2.1.5.3 



10.2.1.6 



Wrong parameters 



Table 10.14: Status byte coding - wrong parameters 



SW1 


SW2 


Description 


'6A' 


'80' 


- Incorrect parameters in the data field 


'6A' 


'81' 


- Function not supported 


'6A' 


'82' 


- File not found 


'6A' 


'83' 


Record not found 


'6A' 


'85' 


Lc inconsistent with TLV structure 


'6A' 


'86' 


- Incorrect parameters PI -P2 


'6A' 


'87' 


Lc inconsistent with P1 -P2 


'6A' 


'88' 


- Referenced data not found 



Application errors 

Table 10.15: Status byte coding - application errors 



SW1 


SW2 


Error description 


'98' 


'50' 


- INCREASE cannot be performed, max value reached. 


'98' 


'62' 


- Authentication error, application specific 



NOTE: Applications may define their own error codes. 

1 0.2.2 Status Words of the Commands 

The following table shows for each command the possible status conditions returned (marked by an asterisk *). 
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Table 10.16: Commands and status words 



Status 
Words 


w 
m 

r— 
m 
o 

H 


H 
C 


c 

D 

> 

H 

m 

□0 

> 

3D 

-< 


C 
-D 
D 
> 

H 

m 

3D 

m 
O 
O 

30 
O 


30 

m 
> 
o 

DO 

-z. 
> 

30 

< 


30 

D 
30 

m 
o 
o 

30 
D 


m 
> 

3D 
O 

3D 

m 
o 
o 

3D 
D 


-z. 
o 

3D 

m 
> 

m 


< 

m 

3D 

-n 

< 

-z. 


a 

> 
z. 
CD 
m 

■D 

z 


D 

cn 
> 

DO 

m 

-D 

z 


m 

z 
> 

DO 

r— 
m 

■D 

z 


c 
z 

00 

I— 
O 
o 

7^ 

-D 

Z 


D 

m 
> 
o 

< 

m 

-n 

i— 
m 


> 

o 

< 

> 

H 

m 

-n 

[— 
m 


> 

c 

H 

m 

z 

H 

o 

m 


H 

m 

30 

z 
> 

r- 
-a 

30 

O 
-n 

i— 
m 


m 

z 
< 
m 

5 

■D 

m 


-n 
m 


H 

m 

3D 

z 
> 

r- 
3D 

m 
w 

■D 

O 
z 
w 
m 


> 
z 
> 
o 
m 

o 

> 

z 
z 
m 

[— 


90 00 

91 XX 
93 00 
98 50 
98 62 
62 00 
62 81 
62 82 
62 83 

62 84 

63 00 

63 CX 

64 00 

65 00 
65 81 
67 00 
69 81 
69 82 
69 83 
69 84 
69 85 
69 86 
6A81 
6A82 
6A83 
6A86 
6A87 
6A88 
6B00 
6E00 
6F00 


* 

* 
* 

* 
* 


* 

* 
* 


* 

* 
* 
* 

* 

* 


* 

* 
* 
* 

* 
* 

* 


* 


* 
* 

* 

* 
* 

* 


* 


* 

* 
* 
* 

* 

* 


* 

* 
* 
* 

* 
* 

* 
* 


* 

* 
* 
* 

* 
* 

* 
* 


* 

* 
* 
* 

* 
* 

* 
* 


* 
* 


* 

* 
* 
* 

* 
* 

* 
* 


* 

* 
* 

* 
* 


* 

* 

* 
* 


* 
* 

* 
* 

* 
* 

* 
* 


* 


* 
* 

* 

* 

* 
* 


* 


* 

* 
* 

* 

* 


* 
* 

* 

* 
* 



The responses '91 XX', and '93 00' can only be given by a UICC to a Terminal supporting US AT 

(see 3GTS 31.111 [4]). 



10.3 Logical channels 

Only the basic channel is currently used. 



11 



Commands 



11.1 Generic commands 

This subclause lists the basic command and response APDU formats that are supported by applications residing on a 
UICC. Commands used to manage an application are not defined in the present document. 
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In the subsequent subclauses, only the response data is listed. For the coding of the status words, see subclause 10.2. 

11.1.1 SELECT 



11.1.1.1 



Functional description 



This function selects a file according to the methods described in clause 8.4. After a successful selection the record 
pointer is undefined. 

Input: 

file ID, application ID, path or empty. 
Output: 

if the selected file is the MF, a DF or an ADF: 

file ID, total memory space available, PIN enabled/disabled indicator, PIN status and other application 
specific data; 
if the selected file is an EF: 

file ID, file size, access conditions, invalidated/not invalidated indicator, structure of EF and length of the 
records in case of linear fixed structure or cyclic structure. 



11.1.1.2 



Command Parameters and Data 



Code 


Value 


CLA 


As specified in 10.1.1 


INS 


As specified in 10.1.2 


P1 


Selection control, see table 1 1 .1 


P2 


Selection control, see table 1 1 .2 


Lc 


Length of subsequent data field or empty 


Data 


File ID, DF name, or path to file, according to PI 


Le 


Empty, '00', or maximum length of data expected in 
response 



Table 11.1: Coding of PI 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


Cleaning 


























Select DF, EFor MF by file id 























1 


Select child DF of the current DF 




















1 


1 


Select parent DF of the current DF 

















1 








Selection by DF name - see NOTE 














1 











Select by path from MF 














1 








1 


Select by path from current DF 


NOTE: This is selection by AID 



Table 11.2: Coding of P2 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


Meaning 


- 


X 


1 


X 





- 


- 


- 


- 


- 


Application session control, see note 2. 

- Activation/Reset 

- Termination 





- 


- 








1 








Return FOP template 





- 


- 





1 


1 








No data returned 


N0TE1 : Whether the FCI information is returned or not depends on the type of APDU 
N0TE2: This only applies when P1 indicates SELECT by DFname 



To avoid ambiguities when P1=P2='00', the following search order applies when selecting a file with a File ID (FID) as 
a parameter: 

immediate children of the current DF; 

the parent DF; 

the immediate children of the parent DF. 
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11.1.1.3 Response Data 



Byte(s) 


Description 


Length 


1 


FCP template tag = '62' 


1 


2 (to 3) 


Length of FCP template 


1 or 2 


3 or 4 to Lr 


FCP template 


X 



The response data contains the File Control Parameters (FCP) template of the selected file. The contents of the FCP 
depends on the selected file. See below for the list of TLV that are returned in each case. 

The value part of the FCP template data object consists of data objects, as shown in the subclause below. It is 
mandatory for data objects to be provided in the order given in the description of each response. New data objects can 
be added to the end of the response data. The terminal shall ignore Data Objects with tags it does not support. 

11.1.1.3.1 Response for MF, DF or ADF 

This subclause lists the TLVs returned when an MF, DF or ADF is selected. 

Table 11.3: Response for MF, DF, or ADF with FCP Template 



Description 


Tag 


Section 


Status 


File Descriptor 


'82' 


11.1.1.4.3 


M 


File Identifier 


'83' 


11.1.1.4.4 


CI 


DF name (AID) 


'84' 


11.1.1.4.5 


C2 


Proprietary information 


'A5' 


11.1.1.4.6 


M 


Life Cycle Status Integer 


'8A' 


11.1.1.4.9 


M 


Security attributes 


'86', '8B', 
'SC or 'AB' 


11.1.1.4.7 


C3 


PIN Status Template DO 


'C6' 


11.1.1.4.10 


M 


Total file size 


'81' 


11.1.1.4.2 





M: Mandatory 

0: Optional 

CI : The File identifier is mandatory for a DF or the MF. For a ADF the File 

identifier is optional. 
C2: DF name is mandatory for only ADF. 
C3: Exactly one shall be present. 



11.1.1.3.2 Response for an EF 

This subclause lists the TLVs returned when an EF is selected. 



Table 11.4: Response for an EF with FCP Template 



Description 


Tag 


Subclause 


Status 


File Descriptor 


'82' 


11.1.1.4.3 


M 


File Identifier 


'83' 


11.1.1.4.4 


M 


Proprietary information 


'A5' 


11.1.1.4.6 


M 


Security attributes 


'86', '88', 
'8C', or 'AB' 


11.1.1.4.7 


CI 


Life Cycle Status Integer 


'8A' 


11.1.1.4.9 


M 


File size 


'80' 


11.1.1.4.1 


M 


Total file size 


'81' 


11.1.1.4.2 





Short file identifier (SFI) 


'88' 


11.1.1.4.8 





M: Mandatory. 

0: Optional. 

CI :Exactly one shall be present. 
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11.1.1.4 



File Control Parameters 



11.1.1.4.1 



File size 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'80' 


1 


2 


Length 


'02' 


1 


3 to 4 


Number of data bytes in the file, excluding 
structural information 




2 



The range of file size is between '0000' and 'FFFF' and the most significant byte comes first in the value field. 

For transparent EF, file size is the length of the body part of the EF, and for linear fixed or cyclic EF, it is the record 
length multiplied by the number of records of the EF. 



11.1.1.4.2 



Total file size 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'81' 


1 


2 


Length 


'02' 


1 


3 to 4 


Number of data bytes in the file, including 
structural information if any. 




2 



The range of total file size is between '0000' and 'FFFF' and the most significant byte comes first in the value field. 

11.1.1.4.3 File Descriptor 



Byte(s) 


Description 


Status 


Value 


Length 


1 


Tag 


M 


'82' 


1 


2 


Length 


M 


'02' or '05' 


1 


3 


File descriptor byte (see table 1 1 .5) 


M 




1 


4 


Data coding byte 


M 


'20' 


1 


5 to 6 


Record length 


C 


'0001 'to 
'OOFF' 


2 


7 


Number of records 


C 


'01'to'FE' 


1 


IVI: Mandatory. 

C: These bytes are mandatory for linear fixed and cyclic files, otherwise they are not applicable. 



File descriptor. 
Contents: File descriptor specifies the file accessibility, and the file type and structure. 

Coding: see table below: 
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Table 11.5: File descriptor byte 



b8 


b7 


bS 


b5 


b4 


b3 


b2 


b1 


Meaning 





X 


- 


- 


- 


- 


- 


- 


File accessibility 








- 


- 


- 


- 


- 


- 


Not shareable file 





1 


- 


- 


- 


- 


- 


- 


Shareable file 





- 


X 


X 


X 


- 


- 


- 


File type 





- 











- 


- 


- 


Working EF 





- 








1 


- 


- 


- 


Internal EF 





- 





1 





- 


- 


- 


RFU 





- 





1 


1 


- 


- 


- 





- 


1 








- 


- 


- 





- 


1 





1 


- 


- 


- 





- 


1 


1 





- 


- 


- 





- 


1 


1 


1 


- 


- 


- 


DForADF 





- 


- 


- 


- 


X 


X 


X 


EF structure 





- 


- 


- 


- 











No information given 





- 


- 


- 


- 








1 


Transparent 





- 


- 


- 


- 





1 





Linear fixed 





- 


- 


- 


- 





1 


1 


RFU 





- 


- 


- 


- 


1 











- 


- 


- 


- 


1 





1 





- 


- 


- 


- 


1 


1 





Cyclic 





- 


- 


- 


- 


1 


1 


1 


RFU 


1 


X 


X 


X 


X 


X 


X 


X 


RFU 



Data coding byte. 

Coding: The data coding byte can be used different according to table 86 in ISO/IEC 7816-4 [13]. For the 

present document, the value '20' (proprietary) is defined as "don't care" and the byte shall not be used by the 

UICC. 

Record length. 

Contents: record length specifies the length of a record when a record structured file has been selected. 

Coding: the record length shall be present if a record structured file (i.e. for linear fixed or cyclic files) is 
selected. In this case it indicates the length the records on 2 bytes. Most significant byte comes first in the value 
field. 

Number of records. 

Contents: number of records specifies the number of records in a record structured file. 

Coding: the number of records shall be present if a record structured file (i.e. for linear fixed or cyclic files) is 
selected. In this case it indicates the number of records on 1 byte. 



11.1.1.4.4 



File identifier 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'83' 


1 


2 


Length 


'02' 


1 


3 to 4 


File identifier 




2 



11.1.1.4.5 



DF name 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'84' 


1 


2 


Length 


1 • X' 16 


1 


3 to 2+X 


DF name 




X 



DF name is a string of bytes, the AID, which is used to uniquely identify an application dedicated file in the card. 
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11.1.1.4.6 Proprietary information 

This is a constructed TLV object. 



Byte(s) 


Description 


Length 


1 


Proprietary information constructed Tag = 'A5' 


1 


2 


Lengtii 


1 


3 to 2+X 


Proprietary data, constructed 


X 



The following TLV objects are defined for the proprietary template (tag'AS'). 



Description 


Tag 


Status 


Clause 


U ICC characteristics 


'80' 


M 


11.1.1.4.6.1 


Application power consumption 


'81' 





11.1.1.4.6.2 


M: IVIandatoryO: Optional 



An application may supply more than one Application power consumption Data Object. 
11.1.1.4.6.1 Dice Characteristics 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'80' 


1 


2 


Length 


'01' 


1 


3 


UICC characteristics byte (see table 1 1 .6) 




1 



Table 11.6: UICC characteristics byte 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


Meaning 


- 


- 


- 


- 


X 


X 


- 




Clock stop allowed 


- 


- 


- 


- 








- 




No preferred level 


- 


- 


- 


- 





1 


- 




High level preferred 


- 


- 


- 


- 


1 





- 




Low level preferred 


- 


- 


- 


- 


1 


1 


- 




RFU 


- 


- 


- 


- 


X 


X 


- 





Clock stop not allowed 


- 


- 


- 


- 








- 





Never 


- 


- 


- 


- 





1 


- 





Unless at high level 


- 


- 


- 


- 


1 





- 





Unless at low level 


- 


- 


- 


- 


1 


1 


- 





RFU 


- 


- 


- 


X 


- 


- 


- 


- 


Supply voltage class A 


- 


- 


X 


- 


- 


- 


- 


- 


Supply voltage class B 


- 


X 


- 


- 


- 


- 


- 


- 


Supply voltage class C 


X 


- 


- 


- 


- 


- 


X 


- 


RFU (shall be set to 0) 



If bit bl is coded '1', stopping the clock is allowed at high or low level. In this case bit b3 and b4 give information about 
the preferred level (high or low, respectively) at which the clock may be stopped. 

If bl is coded '0', the clock maybe stopped only if the mandatory condition b3 = '1' (i.e. stop at high level) orb4 = '1' 
(i.e. stop at low level) is fulfilled. If all 3 bits are coded '0', then the clock shall not be stopped. 

A supply voltage class, as defined in subclause 6.2.1, is supported if the bit is coded as a '1'. If the voltage class is not 
supported the bit is coded as '0'. 



11.1.1.4.6.2 



Application power consumption 



The application power consumption is indicated by tag '81' within the constructed TLV object. The first byte indicates 
the supply voltage at which the power consumption is measured. The coding of this byte is the same as for the supply 
voltage class indication in the ATR, see table 6.1. Unused bits are set to RFU. The second byte indicates the power 
consumption in mA. Bits b8-b7are RFU. Bits b6-bl indicates the power consumption of the application in mA. The 
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power consumption is measured at the frequency indicated in the 'Power comsumption reference frequency' field for 
the application, averaged over 1 ms or at the maximum clock frequency supported by the UICC if no indication is 
given. The terminal shall ignore the application power consumption values '00' and 'FF'. A value higher than 3C shall 
not be interpreted by the terminal and is not to be used. The terminal may still accept the application. 

The terminal shall evaluate the power consumption value given in the response. If the power supply class indicated in 
the response is not the currently used the terminal shall recalculate the value to the currently used supply voltage class. 
The terminal shall accept the application if the recalculated value is within the specification limts set for the currently 
used supply voltage class. The terminal may accept an application that exceeds the specified value if it can support the 
power consumption indicated by the application. 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'81' 


1 


2 


Length 


'03' 


1 


3 


Supply voltage class at which the power 
consumption is measured 




1 


4 


Application power consumption 


'01 -3C' 


1 


5 


Power comsumption Reference Frequency 


'OA'-'FF' 


1 



The Power comsumption Reference Frequency is coded in Hexadecimal format. The resolution is 0. 1 MHz, i.e. 'OA' is 
1 MHz and 'FE' is 25.4 MHz. The value 'FF' indicates that no reference frequency is indicated. 



11.1.1.4.7 

11.1.1.4.7.1 



Security attributes 
Compact Format 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'8C' 


1 


2 


Length 


X 


1 


3 


AM byte 




1 


X-1 


SC bytes 




X+2 



The value of the AM byte is defined in ISO/IEC 7816-9 [17]. The amount of SC bytes depends upon the value of the 
AM byte. There shall be a SC byte present for each bit set to '1' in the AM byte except forbS. The value of the SC byte 
is defined in ISO/IEC 7816-9. 



11.1.1.4.7.2 



Expanded Format 



Byte(s) 


Description 


Value 


Length 


Comment 


1 


Tag 


'AB' 


1 




2 


Length 


X-2 


1 




3 


AM DO tag 


'8X' see N0TE1 


1 


Security 
Rule #1 


4 


Length 


X 


1 


5+X 


AM DO 


NOTE 2 


X 


6+X 


SC DO tag 


N0TE2 


1 


7+X 


Length 


Y 


1 


8+X+Y 


SC DO 


N0TE2 


Y 


























3 


AM DO tag 


'8X' see N0TE1 


1 


Security 
Rule #N 


4 


Length 


W 


1 


5+W 


AM DO 


NOTE 2 


W 


6+W 


SC_DO tag 


N0TE2 


1 


7+W 


Length 


Z 


1 


8+W+Z 


SC DO 


N0TE2 


Z 


N0TE1 : The value of 'X' is dependent on the usage of the AM DO see 781 6-9 [1 7]. 
N0TE2: The value of the AM DO and the SC DO is defined in ISO/IEC 781 6-9 [1 7]. 
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1 1 .1 .1 .4.7.3 Referenced to Expanded Format 

If the length of the data following tag'SB' = '03' the following definition applies: 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'8B' 


1 


2 


Length 


3 


1 


3-4 


EFarr File ID 




2 


5 


EFarr Record number 




1 



If the length of the data following tag'SB' is '02' + X x '02' the following definition applies: 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'8B' 


1 


2 


Length 


'02' + X X '02' 


1 


3-4 


EFarr File ID 




2 


X+4 


SEID 




1 


X+5 


EFarr Record number 






NOTE: For each increment of X a new set of SEID and an EF^rr Record numbers are 
introduced 



11.1.1.4.8 



Short file identifier 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'88' 


1 


2 


Length 


'00' or '01' 


1 


3 


Short file identifier 




Oor1 



If the TLV is not present, the SFI value is the 5 least significant bits (bits b5 to bl) of the file identifier. 

If the TLV is present but empty (i.e. length is 0), the SFI is not supported for the selected file. 

If the length of the TLV is 1, the SFI value is indicated in the 5 most significant bits (bits b8 to b4) of the TLV value 
field. In this case, bits b3 to bl shall be set to 0. 



11.1.1.4.9 



Life Cycle Status Integer 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'8A' 


1 


2 


Length 


1 


1 


3 


Life Cycle Status Integer, see table 1 1 .7 




1 



Table 11.7: Coding of Life Cycle Status Integer 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


Meaning 


























No information given 























1 


Creation state 




















1 


1 


Initialisation state 

















1 


- 


1 


Operational state - activated 

















1 


- 





Operational state - deactivated 














1 


1 


- 


- 


Termination state 


^0 


X 


X 


X 


X 


Proprietary 


Any other value 


RFU 
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11.1.1.4.10 



PIN status template DO 



This TLV object contains the PIN status information for a DF and which PINs are used for access to the DF and its 
child EFs. PIN is indicated in this data object using the key reference tag'83' as defined in ISO/IEC 7816-4 [13]. The 
content of the constructed PIN status TLV Data Object tag'C6' depends on the length (see below). 



Byte(s) 


Description 


Value 


Length 


1 


Tag 


'C6' 




2 


Length 






3 


PS DO tag 


'90' 




4 


Length 


X 




X+4 


PS DO 




X 


X+5 


Usage qualifier DO tag, see NOTE 2 


'95' 




X+6 


Length 


'01' 




X+7 


Usage qualifier, see section 9.C.1 






X+8 


Key reference tag 


'83' 




X+9 


Length 


'01' 




X+10 


Key reference (PIN) 


See table 
9.A.2 




NOTEl : There may be one or more key reference tags following the PS_DO. 
NOTE2: This is optional. 



The usage qualifier DO indicates if the key reference data object (PIN) following it is to be used for verification or not. 
If this data object is present it shall preceed the key reference data object it is associated with. 

For the PS_DO coding see subclause 9.C.I. For each bit set to '1' in the PS byte there shall be a corresponding key 
reference in the PS_DO. The number of key reference tags (tag'83') indicates how many different PINs are used for 
access in the selected DF and its children. 

11.1.2 STATUS 

11.1.2.1 Functional description 

This function returns information concerning the current directory or current application. 

In addition, according to the application specification, it may be used to indicate to the application in the UICC that its 
session activation procedure has been successfully executed or that its termination procedure will be executed. 

NOTE: these indications may be used to synchronise the applications in the ME and in the UICC. 

Input: 

none. 
Output: 

One of the following: 

FCP of the current directory; 

The DFname TLV Data Object of the currently selected application; 
- No data returned. 

1 1 .1 .2.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


Indication of application status (see table 1 1 .8) 


P2 


See table 11.9. 


Le 


Empty, '00', or maximum length of data expected 
In response. 
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Table 11.8: Coding of P1 



b8 


b7 


b6 


b5 


b4 


b3 


B2 


b1 


Cleaning 


























No indication 























1 


Current application is initialised in 
the ME 




















1 





ME will initiate the termination of the 
current application 



Table 11.9: Coding of P2 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


lUleaning 


























Response parameters and data are 
identical to the response parameters and 
data of the SELECT command. 























1 


The DFname TLV-object of the currently 
selected application is returned. 














1 


1 








No data returned. 


Any other value 


RFU. 



11.1.3 READ BINARY 



11.1.3.1 



Functional description 



This function reads a string of bytes from the current transparent EF. This function shall only be performed if the READ 
access condition for this EF is satisfied. 

If the command is applied to an EF without transparent structure then the command shall be aborted. 

Input: 

- relative address and the length of the string. 

Output: 

string of bytes. 

11.1 .3.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


See table 11.10. 


P2 


Offset low. 


Lc 


Not present. 


Data 


Not present. 


Le 


Number of bytes to be read. 



Table 11.10: Coding of PI 



b8 


B7 


b6 


b5 


b4 


b3 


b2 


b1 


Meaning 





X 


X 


X 


X 


X 


X 


X 


b7-b1 is the offset to the first byte to read - 
P2 is the low part of the offset 


1 








X 


X 


X 


X 


X 


SFI referencing used, b1-b5 are the SFI 
and P2 is the offset to the first byte to read 
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Response data: 



Byte(s) 


Description 


Length 


1-Le 


Data read 


Le 



11.1.4 UPDATE BINARY 



11.1.4.1 



Functional parameters 



This function updates the current transparent EF with a string of bytes. This function shall only be performed if the 
UPDATE access condition for this EF is satisfied. An update can be considered as a replacement of the string already 
present in the EF by the string given in the update command. 

Input: 

- relative address and the length of the string; 

- string of bytes. 
Output: 

none. 

1 1 .1 .4.2 Command parameters and data 



Code 


Value 


OLA 


As specified in 10.1.1 


INS 


As specified in 10.1.2 


P1 


See table 11.10 


P2 


Offset low 


Lc 


Length of the subsequent data field 


Data 


String of data to be updated 


Le 


Not present 



Coding of parameter PI and P2 are identical to the coding of PI and P2 in the READ BINARY command. 

11.1.5 READ RECORD 

11.1.5.1 Functional description 

This function reads one complete record in the current linear fixed or cyclic EF. The record to be read is described by 
the modes below. This function shall only be performed if the READ access condition for this EF is satisfied. The 
record pointer shall not be changed by an unsuccessful READ RECORD function. 

Four modes are defined: 

CURRENT: The current record is read. The record pointer is not affected. 

ABSOLUTE: The record given by the record number is read. The record pointer is not affected. 

NEXT: The record pointer is incremented before the READ RECORD function is performed and the pointed record 
is read. If the record pointer has not been previously set within the selected EF, then READ RECORD (next) 
shall read the first record and set the record pointer to this record. 

If the record pointer addresses the last record in a linear fixed EF, READ RECORD (next) shall not cause the 
record pointer to be changed, and no data shall be read. 

If the record pointer addresses the last record in a cyclic EF, READ RECORD (next) shall set the record 
pointer to the first record in this EF and this record shall be read. 
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PREVIOUS: The record pointer is decremented before the READ RECORD function is performed and the pointed 
record is read. If the record pointer has not been previously set within the selected EF, then READ RECORD 
(previous) shall read the last record and set the record pointer to this record. 

If the record pointer addresses the first record in a linear fixed EF, READ RECORD (previous) shall not 
cause the record pointer to be changed, and no data shall be read. 

- If the record pointer addresses the first record in a cyclic EF, READ RECORD (previous) shall set the record 
pointer to the last record in this EF and this record shall be read. 

Input: 

mode, record number (absolute mode only) and the length of the record. 
Output: 

the record. 

1 1 .1 .5.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


Record number. 


P2 


IVIode, see table 11.11. 


Lc 


Not present. 


Data 


Not present. 


Le 


Number of bytes to be read. 



Table 11.11: Coding of P2 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


Cleaning 

















- 


- 


- 


Currently selected EF 


X 


X 


X 


X 


X 


- 


- 


- 


Short File identifier (from 1 to 30) 


- 


- 


- 


- 


- 





1 





Next record 


- 


- 


- 


- 


- 





1 


1 


Previous record 












1 








Absolute/ current mode, the record number 
is given in PI with PI ='00' denoting the 
current record 



For the modes "next" and "previous" PI has no significance within the scope of this specification and shall be set to '00' 
by the Terminal. 

Response data: 



Byte(s) 


Description 


Length 


1-Le 


Data read 


Le 



11.1.6 UPDATE RECORD 



11.1.6.1 



Functional description 



This function updates one specific, complete record in the current linear fixed or cyclic EF. This function shall only be 
performed if the UPDATE access condition for this EF is satisfied. The UPDATE can be considered as a replacement 
of the relevant record data of the EF by the record data given in the command. The record pointer shall not be changed 
by an unsuccessful UPDATE RECORD function. 

The record to be updated is described by the modes below. Four modes are defined of which only PREVIOUS is 
allowed for cyclic files: 

- CURRENT: The current record is updated. The record pointer is not affected. 
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- ABSOLUTE: The record given by the record number is updated. The record pointer is not affected. 

- NEXT: The record pointer is incremented before the UPDATE RECORD function is performed and the pointed 
record is updated. If the record pointer has not been previously set within the selected EF, then UPDATE 
RECORD (next) shall set the record pointer to the first record in this EF and this record shall be updated. If the 
record pointer addresses the last record in a linear fixed EF, UPDATE RECORD (next) shall not cause the 
record pointer to be changed, and no record shall be updated. 

PREVIOUS: For a linear fixed EF the record pointer is decremented before the UPDATE RECORD function is 
performed and the pointed record is updated. If the record pointer has not been previously set within the selected 
EF, then UPDATE RECORD (previous) shall set the record pointer to the last record in this EF and this record 
shall be updated. If the record pointer addresses the first record in a linear fixed EF, UPDATE RECORD 
(previous) shall not cause the record pointer to be changed, and no record shall be updated. 

For a cyclic EF the record containing the oldest data is updated, the record pointer is set to this record and this 
record becomes record number 1 . 

Input: 

mode, record number (absolute mode only) and the length of the record; 

the data used for updating the record. 
Output: 

none. 

11.1 .6.2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


Record number. 


P2 


IVIode, see table 11.11. 


Lc 


Length of the subsequent data field. 


Data 


String of data to be updated. 


Le 


Not present. 



Coding of parameter P2 is identical to the coding of P2 in READ RECORD command. 

For the modes "next" and "previous" PI has no significance and shall be set to '00' by the Terminal. To ensure 
backward compatibility, the UICC shall not interpret the value given by the Terminal. 

11.1.7 SEARCH RECORD 



11.1.7.1 



Functional description 



This function searches through a linear fixed or cyclic EF to find record(s) containing a specific pattern. This function 
shall only be performed if the READ access condition for this EF is satisfied. The search starts: 

either at the first byte of the record(s) (simple search), or 

from a given offset in the record(s); or 

from the first occurrence of a given byte in the record(s). 

The response is either empty or contains the, up to the Le specified number of, record number(s) of the records that 
matches the search in the selected EF. 

If one or more matches are found the record pointer shall be set to the first record where the search pattern was found. 

Input: 

search mode (simple/enhanced); 

offset; 
- pattern. 

Output: 
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either none, if Le is empty or no matches where found; or 
at most the number of record(s) number(s) defined in Le. 

11.1 .7.2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


Record number. 


P2 


See table 11.12. 


Lc 


Length of the subsequent data field. 


Data 


- Simple search : search string 

- Enhanced search : search indication (2 bytes) 

followed by search string 

- Proprietary search : proprietary data 


Le 


Empty or maximum length of response data. 
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Table 11.12: Coding Of P2 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


lUleaning 

















- 


- 


- 


Currently selected EF. 


X 


X 


X 


X 


X 


- 


- 


- 


Short File Identifier. 


1 


1 


1 


1 


1 


- 


- 


- 


RFU. 


- 


- 


- 


- 


- 





X 


X 


RFU - see NOTE. 


- 


- 


- 


- 


- 







X 


Simple search. Usage of P1 as a record 
number. 


- 


- 


- 


- 


- 










Start forward search form record indicated 
in PI. 


- 


- 


- 


- 


- 







1 


Start backward search form record 
indicated in P1. 


- 


- 


- 


- 


- 




1 





Enhanced search - see table 11.13. 


- 


- 


- 


- 


- 




1 


1 


Proprietary search. 


NOTE: This value is reserved by ISO/IEC 7816-9 [17]. | 



Table 11.13: Coding of the first byte of the search indication for enhanced search mode 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


Meaning 



















The search starts in the record from the 
offset (absolute position) given in the 
second byte of the search indication. 










1 








The search starts in the record after the first 
occurrence of the value contained in the 
second byte of the search indication. 


- 


- 


- 


- 


- 





X 


X 


RFU - see NOTE. 


- 


- 


- 


- 


- 




X 


X 


Usage of value of PI as a record number. 


- 


- 


- 


- 


- 










Start forward search form record indicated 
in PI. 


- 


- 


- 


- 


- 







1 


Start backward search form record 
indicated in PI. 


- 


- 


- 


- 


- 




1 





Start forward search from next record. 


- 


- 


- 


- 


- 




1 


1 


Start backward search form previous 
record. 


Any other value 


RFU 


NOTE: This value is reserved by ISO/IEC 7816-9 [17]. 



Response data: 



Byte(s) 


Description 


Length 


0-Le 


Record number{s). 


Le 


NOTE: If Le is empty no record numbers will be returned. 



11.1.8 INCREASE 



11.1.8.1 



Functional description 



This function adds the value given by the Terminal to the value of the last increased/updated record of the current cyclic 
EF, and stores the result into the oldest record. The record pointer is set to this record and this record becomes record 
number 1. This function can only be used if this EF has an INCREASE access condition assigned and this condition is 
fulfilled. The INCREASE access condition is indicated in the access rules using AM_DO tag '84'. Tag '84' indicates that 
the INS code for the INCREASE command is indicated as the value in the TLV object (instruction code '32'). The 
INCREASE command can only be used on files that refer to an access rule where this INS code is indicated as part of 
the rule. 

The function does not perform the increase if the result would exceed the maximum value of the record (represented by 
all bytes set to 'FF'). 
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Input: 

value to be added. 
Output: 

value of the increased record; 
- value which has been added. 

11.1 .8.2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


See table 11.14. 


P2 


'00'. 


Lc 


Length of the subsequent data field. 


Data 


Value to be added. 


Le 


Length of the response data. 



Table 11.14: Coding of PI 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


lUleaning 


























Increase the currently selected EF. 


1 








X 


X 


X 


X 


X 


SFI referencing used, b1-b5 are the SFI. 


NOTE: All other values are RFU. 



Response data: 



Byte(s) 


Description 


Length 


1 -X 


Value of the increased record. 


X 


X+1 - X+Lc 


Value which has been added. 


Lc 


NOTE: X denotes the length of the record. 



11.1.9 VERIFY PIN 



11.1.9.1 



Functional description 



The Verify PIN command initiates the comparison in the UICC of the PIN verification data sent from the Terminal with 
the PIN reference data stored in the card. The verification process is subject to the following conditions being fulfilled: 

PIN is not disabled; 

- PIN is not blocked. 

If the access condition for a function to be performed on the last selected file is PIN, then a successful verification of the 
relevant PIN is required prior to the use of the function on this file unless the PIN is disabled. 

If the PIN presented is correct, the number of remaining PIN attempts for that PIN shall be reset to its initial value 3. 

If the PIN presented is false, the number of remaining PIN attempts for that PIN shall be decremented. After 3 
consecutive false PIN presentations, not necessarily in the same card session, the respective PIN shall be blocked and 
the access condition can never be fulfilled until the UNBLOCK PIN function has been successfully performed on the 
respective PIN. 

Input: 

indication PIN or empty. 
Output: 

none. 
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11.1.9.2 Retry counter Value 

The value of the retry counter specifies how many verification attempts are left. It can be obtained in the following 

ways. 

The VERIFY command is sent to the UICC with parameter P2 indicating PIN for which the retry counter value 
is to be retrieved with an empty data field (response SWl, SW2 '63CX' where X indicates the number of further 
allowed retries). 

In case of an unsuccessful PIN verification the UICC returns the remaining retry value in the response 
parameters SWl, SW2 (response '63CX' where X indicates the number of further allowed retries). 

11.1 .9.3 Command parameters: 



Code 


Value 


OLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


'00'. 


P2 


Qualifier of the reference data, see table 11.15. 


Lc 


Length of the subsequent data field = '00' or '08'. 


Data 


PIN value. 


Le 


Not present. 



Table 11.15: Coding of P2 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


Cleaning 


























Not supported. 





- 


- 


- 


- 


- 


- 


- 


Global reference data (e.g. MF specific 
PIN). 


1 


- 


- 


- 


- 


- 


- 


- 


Specific reference data (e.g. DF 
specific/application dependent PIN). 


- 


X 


X 


- 


- 


- 


- 


- 


'00' (other values are RFU). 


- 


- 


- 


X 


X 


X 


X 


X 


Reference data number ('01 ' to '1 F'). 



The five least significant bits of parameter P2 specify the PIN key reference number(see subclause 9.5.1). 
Command data: 



Byte(s) 


Description 


Length 


1 -8 


PIN value 


8 



11.1.10 CHANGE PIN 
11.1.10.1 Functional description 

The Change PIN command is used to initiate the comparison of the verification data with the PIN, and then to 
conditionally replace the existing PIN with the new PIN sent to the UICC in the command. 

This function assigns a new value to the relevant PIN subject to the following conditions being fulfilled: 

PIN is not disabled; 

- PIN is not blocked. 

The old and new PIN shall be presented. 

If the old PIN presented is correct, the number of remaining PIN attempts for that PIN shall be reset to its initial value 3 
and the new value for the PIN becomes valid. 
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If the old PIN presented is false, the number of remaining PIN attempts for that PIN shall be decremented and the value 
of the PIN is unchanged. After 3 consecutive false PIN presentations, not necessarily in the same card session, the 
respective PIN shall be blocked and the access condition can never be fulfilled until the UNBLOCK PIN function has 
been performed successfully on the respective PIN. 

Input: 

- indication of PIN, old PIN, new PIN. 
Output: 
none. 

1 1 .1 .1 0.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


'00'. 


P2 


As specified for the VERIFY PIN command, see 
11.1.9. 


Lc 


Length of the subsequent data field = '1 0'. 


Data 


Old PIN value, new PIN value. 


Le 


Not present. 



NOTE: "Change PIN" is named "exchange reference data" in ISO/IEC 7816-8 [16]. 



Byte(s) 


Description 


Length 


1 -8 


Old PIN value 


8 


9-16 


New PIN value 


8 



11.1.11 DISABLE PIN 



11.1.11.1 



Functional description 



The Disable PIN command is used to switch off the requirement to compare the PIN verification data with the PIN 
reference data. The command also allows an indication whether to use an alternative global key reference, if enabled, or 
not when the application PIN is disabled. For universal PIN definition see subclause 9.2.1. Usage of an alternative 
global key reference for user verification is indicated in parameter PI. If an alternative global key reference is used as a 
replacement for the application PIN the verification of the alternative global key reference shall be performed instead of 
the application PIN verification to get access to the application. 

NOTE: The access rules for the application must cater for the case that an alternative global key reference 
replaces the application PIN. It is the responsibility of the application to specify this. 

The successful execution of this function has the effect that files protected by PIN are now accessible as if they were 
marked "ALWAYS", except in the case where the alternative global key reference is to be used as a replacement for the 
disabled PIN. In this case the access condition for files containing only a reference to the disabled PIN is the alternative 
global key reference. For files having more than one global key reference indicated in the access rules the access 
condition is "ALWAYS" after disabling on of the key references used in the access rules. The function DISABLE PIN 
shall not be executed by the selected application when PIN is already disabled or blocked. 

NOTE: Every application must specify whether this function is applicable to all PINs defined for the application. 

If the PIN presented is correct, the number of remaining PIN attempts shall be reset to its initial value 3 and PIN shall 
be disabled. 

If the PIN presented is false, the number of remaining PIN attempts shall be decremented and PIN remains enabled. 
After 3 consecutive false PIN presentations, not necessarily in the same card session, the PIN shall be blocked and the 
access condition can never be fulfilled until the UNBLOCK PIN function has been successfully performed on PIN. 

Input: 



£75/ 



3G TS 31.101 version 3.2.0 Release 1999 



80 



ETSI TS 131 101 V3.2.0 (2000-07) 



- PIN. 
Output: 
none. 



11.1.11.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


PI 


See table 11.16. 


P2 


As specified for the VERIFY PIN command, see 
11.1.9. 


Lc 


Length of the subsequent data = '08'. 


Data 


PIN value. 


Le 


Not present. 



Table 11.16: Coding of PI 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


b1 


lUleaning 


























Verification data present in data field 























1 


Reserved by ISO/IEC 7816-8 [16] 


1 


- 


- 


- 


- 


- 


- 


- 


Verification data present, and use reference 
data number as verification replacement 


- 


X 


X 


- 


- 


- 


- 


- 


'00' (other values are RFU) 


- 


- 


- 


X 


X 


X 


X 


X 


Global key reference data number ('01' to 
'IF') 



Command data: 



Byte(s) 


Description 


Length 


1 -8 


PIN value 


8 



11.1.12 ENABLE PIN 
11.1.12.1 Functional description 

The Enable PIN command is used to switch on the requirement to compare the PIN verification data with the PIN 
reference data. It is the reverse function of DISABLE PIN. If an alternative global key reference has been used as a 
replacement for the application PIN. The usage of the alternative global key reference as a replacement shall be disabled 
upon enabling the PIN for which the alternative global key reference has been a replacement (setting the usage qualifier 
in the PS_DO template data object for the alternative global key reference to don't use = '00'). 

The function ENABLE PIN shall not be executed by the selected application when PIN is already enabled or blocked. 

Every application shall specify whether this function is applicable to all PINs defined for the application. 

If the PIN presented is correct, the number of remaining PIN attempts shall be reset to its initial value 3 and PIN shall 
be enabled. 

If the PIN presented is false, the number of remaining PIN attempts shall be decremented and PIN remains disabled. 
After 3 consecutive false PIN presentations, not necessarily in the same card session, PIN shall be blocked and may 
optionally be set to "enabled". Once blocked, the PIN can only be unblocked using the UNBLOCK PIN function. If the 
PIN is blocked and "disabled", the access condition shall remain granted. If the PIN is blocked and "enabled", the 
access condition can never be fulfilled until the UNBLOCK PIN function has been successfully performed on PIN. 

Input: 
- PIN. 
Output: 
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none. 



1 1 .1 .1 2.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


'00'. 


P2 


As specified for the VERIFY PIN command, see 
11.1.9. 


Lc 


Length of the subsequent data = '08'. 


Data 


PIN value. 


Le 


Not present. 



Command data: 



Byte(s) 


Description 


Length 


1 -8 


PIN value 


8 



11.1.13 UNBLOCK PIN 

11.1.13.1 Functional description 

The Unblock PIN command is used to reset the PIN retry counter to its initial value and then to conditionally set a new 
PIN value. This function may be performed whether or not the relevant PIN is blocked (e.g. by 3 consecutive wrong 
PIN presentations). 

If the UNBLOCK PIN presented is correct, the value of the PIN, presented together with the UNBLOCK PIN, is 
assigned to that PIN, the number of remaining UNBLOCK PIN attempts for that UNBLOCK PIN is reset to its initial 
value 10 and the number of remaining PIN attempts for that PIN is reset to its initial value 3. After a successful 
unblocking attempt the PIN is enabled and the relevant access condition level is satisfied. 

If the presented UNBLOCK PIN is false, the number of remaining UNBLOCK PIN attempts for that UNBLOCK PIN 
shall be decremented. After 10 consecutive false UNBLOCK PIN presentations, not necessarily in the same card 
session, the respective UNBLOCK PIN shall be blocked. A false UNBLOCK PIN shall have no effect on the status of 
the respective PIN itself. 

Input: 

- indication PIN, the UNBLOCK PIN and the new PIN or empty. 
Output: 

none. 

11.1.13.2 Retry counter Value 

The value of the retry counter, is obtained in the following ways: 

- the UNBLOCK PIN command is sent to the UICC with parameter P2 indicating UNBLOCK PIN for which the 
retry counter value is to be retrieved with an empty data field (response SWl, SW2 '63CX', where X indicates 
the number of further allowed retries); 

in case of an unsuccessful PIN verification the UICC returns the remaining retry value in the response 
parameters SVv'l, SW2 (response '63CX', where X indicates the number of further allowed retries). 
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11.1.13.3 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1 


INS 


As specified in 10.1.2 


P1 


'00' 


P2 


As specified fertile VERIFY PIN command (see 
11.1.9) 


Lc 


Length of the subsequent data field = '00' or '1 0' 


Data 


UNBLOCK PIN value, new PIN value 


Le 


Not present 



Command data: 



Byte(s) 


Description 


Length 


1 -8 


UNBLOCK PIN value 


8 


9-16 


New PIN value 


8 



11.1.14 DEACTIVATE FILE 



11.1.14.1 



Functional description 



This function initiates a reversible deactivation of an EF. After a DEACTIVATE FILE function the respective flag in 
the file status shall be changed accordingly. This function shall only be performed if the DEACTIVATE FILE access 
condition for the EF is satisfied. 

An deactivated file shall no longer be available within the selected application for any function except for the SELECT 
and the ACTIVATE FILE functions. 

Input: 

none. 
Output: 



11.1.14.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


PI 


As specified for the SELECT command (see 11.1.1). 


P2 


00. 


Lc 


Length of subsequent data field or empty. 


Data 


File ID or path to file, according to PI . 


Le 


Not present. 



11.1.15 ACTIVATE FILE 

11.1.15.1 Functional description 

This function reactivates a deactivated EF. After an ACTIVATE FILE function the respective flag in the file status shall 
be changed accordingly. This function shall only be performed if the ACTIVATE FILE access condition for the EF is 
satisfied. 

Input: 

none. 
Output: 

none. 
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1 1 .1 .1 5.2 Command parameters 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


As specified for the SELECT command (see 11.1.1). 


P2 


00. 


Lc 


Lengtii of subsequent data field or empty. 


Data 


File ID or path to file, according to PI . 


Le 


Not present. 



11.1.16 AUTHENTICATE 

11.1.16.1 Functional description 

An appropriate application shall be selected in the UICC before issuing this command. The function initiates the 
computation of authentication data by the UICC using a challenge sent from the terminal and a secret stored in the 
UICC. 

Input: 

- challenge data. 
Output: 

- authentication and ciphering data. 

1 1 .1 .1 6.2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


PI 


'00'. 


P2 


See table 11.17. 


Lc 


Length of the subsequent data field. 


Data 


Authentication related data. 


Le 


Length of the response data. 



NOTE 1 : Parameter PI ='00' indicates that no information on the algorithm is given. The algorithm is implicitly known 
in the context of the selected application. 



Table 11.17: Coding of P2 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


B1 


lUleaning 


























No information given 





- 


- 


- 


- 


- 


- 


- 


Global reference data (e.g. MF specific 
KEY) 


1 


- 


- 


- 


- 


- 


- 


- 


Specific reference data (e.g. DF 
specific/application dependent KEY) 


- 


X 


X 


- 


- 


- 


- 


- 


'00' (other values are RFU) 


- 


- 


- 


X 


X 


X 


X 


X 


Reference data number ('01 ' to '1 F') 



NOTE 2: Parameter P2='00' indicates that no information on the key is given. The key is implicitly known in the 
context of the selected application. 

Command data: 
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Byte(s) 


Description 


Length 


1-Lc 


Authentication related data (see NOTE). 


Lc 


NOTE: The command data must be specified by each application specific document. 



Response data (generic): 



Byte(s) 


Description 


Length 


1 -Le 


Authentication related data (see NOTE). 


Le 


NOTE: The response data must be specified by each application specific document. 



11.1.17 MANAGE CHANNEL 

The MANAGE CHANNEL command is for further study by 3GPP TSG-T WG3. 

1 1 .2 USAT Commands 
11.2.1 TERMINAL PROFILE 

11.2.1.1 Functional description 

This function is used by the Terminal to transmit its USAT capabilities to the applications present on the UICC. 

Input: 

terminal profile. 
Output: 

none. 

1 1 .2.1 .2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


'00'. 


P2 


'00'. 


Lc 


Length of the subsequent data field. 


Data 


structure and coding defined in 30 TS 31 


111 [4]. 1 


Le 


Not present. 



11.2.2 ENVELOPE 

1 1 .2.2.1 Functional description 

This function is used to transfer USAT information from the UE to the UICC. 

Input: 

- The structure of the data is defined in 3G TS 3 1 . 11 1 [4] . 
Output: 

- the structure of the data is defined in 3G TS 3 1 . 1 1 1 [4] . 
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1 1 .2.2.2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


'00'. 


P2 


'00'. 


Lc 


Lengtii of the subsequent data field. 


Data 


Structure and coding defined in 3G TS 31 .1 1 1 [4]. 


Le 


Empty or maximum length of response data. 



Response data: 

Structure of the response data is defined in 3G TS 3 1 . 1 1 1 [4] for US AT applications. 

11.2.3 FETCH 

1 1 .2.3.1 Functional description 

This function is used to transfer a proactive command from the UICC to the Terminal (e.g. from a USAT application). 

Input: 

none. 
Output: 

data string containing a proactive command for the Terminal (e.g. a USAT command). 

1 1 .2.3.2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


PI 


'00'. 


P2 


'00'. 


Lc 


Not present. 


Data 


Not present. 


Le 


Length of expected data. 



Response data: 

Structure of the response data is defined in 3G TS 31.111 [4] for USAT applications. 

1 1 .2.4 TERMINAL RESPONSE 
1 1 .2.4.1 Functional description 

This function is used to transfer from the Terminal to the UICC the response to a previously fetched proactive command 
(e.g. a USAT command). 

Input: 

data string containing the response. 
Output: 

none. 



£75/ 



3G TS 31.101 version 3.2.0 Release 1999 



86 



ETSI TS 131 101 V3.2.0 (2000-07) 



1 1 .2.4.2 Command parameters and data 



Code 


Value 


CLA 


As specified in 10.1.1. 


INS 


As specified in 10.1.2. 


P1 


'00'. 


P2 


'00'. 


Lc 


Lengtii of the subsequent data field. 


Data 


Structure and coding defined in 3G TS 31 


111 [41. 1 


Le 


Not present. 



12 Transmission Oriented Commands 

This clause lists all transport specific commands. Currently there is only one such command. 



1 2.1 T=0 specific commands 
12.1.1 GET RESPONSE 



12.1.1.1 



Functional description 



The command is used to transmit APDUs from the card to the Terminal, which otherwise could not be transferred by 
the protocol. 

The response data depends on the preceding command. Response data is available after the commands 
AUTHENTICATE, SEARCH RECORD, SELECT and INCREASE. If the command GET RESPONSE is executed, it 
is required that it is executed immediately after the command it is related to (no other command shall come between the 
command/response pair and the command GET RESPONSE). If the sequence is not respected, the selected application 
shall send the status information "technical problem, no precise diagnosis" as a reaction to the GET RESPONSE. 

Since the MF is implicitly selected after activation, GET RESPONSE is also allowed as the first command after 
activation. 

The response data itself is defined in the sub-clause for the corresponding command. 

1 2.1 .1 .2 Command parameters 

Table 12.1 : Parameters for GET RESPONSE 



Code 


Value 


CLA 


As specified in 10.1.1 


INS 


As specified in 10.1.2 


PI 


'00' 


P2 


'00' 


Lc 


Not present 


Data 


Not present 


Le 


'00' or value of SW2 of the previous command 



Response parameters and data: 

The response data is defined in each subclause of the corresponding command. 
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1 3 Application independent files 

13.1 EFdir 

EFdir is a linear fixed file. This file is under the responsibility of the issuer when at the MF level. It can be under a 
different responsibility, when situated at a lower level. 

Table 13.1 : EFdir at MF-level 



Identifier: '2F00' 


Structure: 


Linear fixed 


Mandatory 


SFI: Mandatory 




Record size: 


X bytes 




Update activity: low 


Access Conditions: 
READ 
UPDATE 
DEACTIVATE 
ACTIVATE 




ALW 
ADM 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 -X 


Application template TLV object 


M 


X bytes 



The EF consists of one or more records, with each record able to hold one entry. Each entry in the EFdir is an 
application template Data Object (DO) as defined in ISO/IEC 7816-5 [14]. An application template DO is a constructed 
BER-TLV object with a maximum length of 127 bytes and has a mandatory AID DO. Within the scope of this 
specification, all other DOs are optional. 

In table 13.2 the coding of the mandatory DOs and the optional DOs that has special meaning to this document. All 
other DOs are according to ISO/IEC 7816-5 [14]. 

Table 13.2: Coding of an application template entry 



Length 


Description 


Status 


1 


Application template tag = '61'. 


M 


1 


Length of the application template = '03'-'7F'. 


M 


1 


Application Identifier tag = '4F'. 


M 


1 


AID length = '01 '-'10'. 


M 


'01 '-'10' 


AID value. For 3G applications, see 
3GTS 31.110 [3]. 


M 


1 


Application label tag = '50'. 





1 


Application label length. 





N0TE1 


Application label value. 





NOTE 1 : The application label is a DO that contains a string of bytes 

provided by the application provider to be shown to the user for 
information, e.g. operator name. The value part of the 
application label shall be coded according to Annex A. In 
ISO/IEC 7816-5 [14] the application label is limited to 16 bytes, 
this does not apply to this specification it is however 
recommended that the number of bytes does not exceed 32. 

NOTE 2: Other DOs from ISO/IEC 7816-5 [14] may, at the application 
issuer's discretion, be present as well. 



1 3.2 EFicciD (ICC Identification) 

This EF provides a unique identification number for the UICC. 
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Table 13.3: EFicqid at MF-level 



Identifier: '2FE2' 




Structure 


transparent 


Mandatory 


File size: 10 bytes 






Update activity: low 


Access Conditions: 
READ 
UPDATE 
DEACTIVATE 
ACTIVATE 




ALW 
NEV 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1-10 


Identification nur 


Tiber 






M 


10 bytes 



Identification number: 

Contents: 

according to CCITT Recommendation E. 1 18 [5]. 
Purpose: 

card identification number. 



Coding: 

BCD, left justified and padded with 'F.' The order of digits is coded as below: 

Byte 1: 



B7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of Digit 1 



MSB of Digit 1 
LSB of Digit 2 



MSB of Digit 2 



Byte 2: 



B7 



b6 



b5 



b4 



b3 



b2 



bl 



etc. 



LSB of Digit 3 



MSB of Digit 3 
LSB of Digit 4 



MSB of Digit 4 



13.3 EFpL (Preferred Languages) 



This EF contains the codes for up to n languages. This information, determined by the user/operator, defines the 
preferred languages of the user, for the UlCC, in order of priority. 
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Table 13.4: EFrl at MF-level 



Identifier: '2F 05' Structure: transparent 


Mandatory 


SFI: Mandatory 




File size: 2n bytes 


Update activity 


: low 


Access Conditions: 

READ ALW 
UPDATE PIN 
DEACTIVATE ADM 
ACTIVATE ADM 


Bytes 


Description 


M/0 


Length 


1 -2 


1^' language code (highest prior) 


M 


2 bytes 


3-4 


2"° language code 





2 bytes 










2n-1 -2n 


nth language code (lowest prior) 





2 bytes 



Coding: 

each language code is a pair of alpha-numeric characters, defined in ISO 639 [6]. Each alpha-numeric 
character shall be coded on one byte using the SMS default 7-bit coded alphabet as defined in 3G TS 23.038 
[1] with bit 8 set to 0. 

Unused language entries shall be set to 'FF FF'. 

13.4 EFarr (Access Rule Reference) 

This EF contains the access rules for files located under the MF in the UICC. If the security attribute tag '8B' is 
indicated in the FCP it contains a reference to a record in this file. 

Table 13.4: EFarr at MF-level 



Identifier: '2F06' 


Structure: 


Linear 


fixed 


Optional 


File size: X 


bytes 






Update activity: low 


Access Conditions: 
READ 
UPDATE 
DEACTIVATE 
ACTIVATE 




ALW 
ADM 
ADM 
ADM 








Bytes 


Description 


M/0 


Length 


1 -X 


Access Rule TLV data objects 


M 


X bytes 



This EF contains one or more records containing access rule information according to the referenced format as defined 
in ISO/IEC 7816-9 [17]. Each record represents an access rule. Unused bytes in the record are set to 'FF'. 



14 Application independent protocol 

14.1 File related procedures 
14.1.1 Reading an EF 

Reading of an EF can be done in two different ways. 

If the short file identifiers are used the following procedure applies: 
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if short file identifiers are used, EFs that support SFI within the Current Directory can be read without 
explicitly selecting the EF. The Terminal selects the DF or ADF and sends a READ command. This contains 
the short file identifier of the EF to be read and the location of the data to be read. If the access condition for 
READ is fulfilled, the application sends the requested data contained in the EF to the Terminal. If the access 
condition is not fulfilled, no data will be sent and an error code will be returned. 

If the short file identifiers are not used the following procedure applies: 

the Terminal selects the EF and sends a READ command. This contains the location of the data to be read. If 
the access condition for READ is fulfilled, the application sends the requested data contained in the EF to the 
Terminal. If the access condition is not fulfilled, no data will be sent and an error code will be returned. 

14.1.2 Updating an EF 

Updating of an EF can be done in two different ways: 

If the short file identifiers are used the following procedure applies: 

if short file identifiers are used , EFs that support SFI within the Current Directory can be updated without 
explicitly selecting the EF. The Terminal selects the DF or ADF and sends an UPDATE command. This 
contains the short file identifier of the EF and the location of the data to be updated and the new data to be 
stored. If the access condition for UPDATE is fulfilled, the application updates the selected EF by replacing 
the existing data in the EF with that contained in the command. If the access condition is not fulfilled, the 
data existing in the EF will be unchanged, the new data will not be stored, and an error code will be returned. 

If the short file identifiers are not used the following procedure applies: 

the Terminal selects the EF and sends an UPDATE command. This contains the location of the data to be 
updated and the new data to be stored. If the access condition for UPDATE is fulfilled, the application 
updates the selected EF by replacing the existing data in the EF with that contained in the command. If the 
access condition is not fulfilled, the data existing in the EF will be unchanged, the new data will not be 
stored, and an error code will be returned. 

14.1.3 Increasing an EF 

Increasing of an EF can be done in two different ways: 

If the short file identifiers are used the following procedure applies: 

If short file identifiers are used, EFs that support SFI within the Current Directory can be increased without 
explicitly selecting the EF. The Terminal selects the DF or ADF and sends an INCREASE command. This 
contains the short file identifier of the EF and the value which has to be added to the contents of the last 
updated/increased record. If the access condition for INCREASE is fulfilled, the application increases the 
existing value of the EF by the data contained in the command, and stores the result. If the access condition is 
not fulfilled, the data existing in the EF will be unchanged and an error code will be returned. 

If the short file identifiers are not used the following procedure applies: 

The Terminal selects the EF and sends an INCREASE command. This contains the value which has to be 
added to the contents of the last updated/increased record. If the access condition for INCREASE is fulfilled, 
the application increases the existing value of the EF by the data contained in the command, and stores the 
result. If the access condition is not fulfilled, the data existing in the EF will be unchanged and an error code 
will be returned. 

NOTE: The identification of the data within an EF to be acted upon by the above procedures is specified within 
the command. For the procedures in subclauses 14.1.1 and 14.1.2 this data may have been previously 
identified using a SEARCH RECORD command, e.g. searching for an alphanumeric pattern. 
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14.2 PIN related procedures 



NOTE: This document specifies only the generic behaviour of a PIN. An application may create a set of PINs 
each with a specific behaviour. 

A successful completion of one of the following procedures grants the access right of the corresponding PIN for an 
application session. This right is valid for all files within the application protected by this PIN. 

After a third consecutive presentation of a wrong PIN to an application, not necessarily in the same application session, 
the PIN status becomes "blocked" and if the PIN is "enabled", the access right previously granted by this PIN is lost 
immediately. 

An access right is not granted if any of the following procedures are unsuccessfully completed or aborted. 

14.2.1 PIN verification 

The Terminal checks the PIN status and the following procedure applies: 

If the PIN status is "blocked" and PIN is "enabled", the procedure ends and is finished unsuccessfully. 

If the PIN status is "blocked" but PIN is "disabled", the procedure ends and is finished successfully. The 
Terminal shall, however, accept applications which do not grant access rights when PIN is "blocked" and 
"disabled". In that case Terminal shall consider those applications as "blocked". 

- If the PIN status is not "blocked" and PIN is "disabled", the procedure is finished successfully. 

- If the PIN status is not "blocked" and PIN is "enabled", the Terminal uses the VERIFY PIN function. If the PIN 
presented by the Terminal is equal to the corresponding PIN stored in the application, the procedure is finished 
successfully. If the PIN presented by the Terminal is not equal to the PIN which protects the application, the 
procedure ends and is finished unsuccessfully. 

14.2.2 PIN value substitution 

The Terminal checks the PIN status. If the PIN status is "blocked" or "disabled", the procedure ends and is finished 
unsuccessfully. 

If the PIN status is not "blocked" and the enabled/disabled indicator is set "enabled", the Terminal uses the CHANGE 
PIN function. If the old PIN presented by the Terminal is equal to the PIN which protects the application, the new PIN 
presented by the Terminal is stored instead of the old one and the procedure is finished successfully. 

If the old PIN and the PIN in memory are not identical, the procedure ends and is finished unsuccessfully. 



14.2.3 PIN disabling 



PIN enabling and disabling may be disallowed by an application. If it is allowed then the following procedures shall be 
followed: 

The Terminal checks the PIN status. If the PIN status is "blocked", the procedure ends and is finished 
unsuccessfully. 

If the PIN status is not "blocked", the Terminal reads the PIN enabled/disabled indicator. If this is set "disabled", 
the procedure ends and is finished unsuccessfully. 

If the PIN status is not "blocked" and the enabled/disabled indicator is set "enabled", the Terminal uses the 
DISABLE PIN function. If the PIN presented by the Terminal is equal to the PIN which protects the application, 
the status of PIN is set "disabled" and the procedure is finished successfully. If the PIN presented by the 
Terminal is not equal to the PIN which protects the application, the procedure ends and is finished 
unsuccessfully. 



£75/ 



3G TS 31.101 version 3.2.0 Release 1999 92 ETSI TS 131 101 V3.2.0 (2000-07) 



14.2.4 PIN enabling 



PIN enabling and disabling may be disallowed by an application. If it is allowed then the following procedures shall be 
followed:- The Terminal checks the PIN status. If the PIN status is "blocked", the procedure ends and is finished 
unsuccessfully. 

If the PIN status is not "blocked", the Terminal reads the PIN enabled/disabled indicator. If this is set "enabled", 
the procedure ends and is finished unsuccessfully. 

If the PIN status is not "blocked" and the enabled/disabled indicator is set "disabled", the Terminal uses the 
ENABLE PIN function. If the PIN presented by the Terminal is equal to the PIN which protects the application, 
the status of PIN is set "enabled" and the procedure is finished successfully. If the PIN presented by the Terminal 
is not equal to the PIN which protects the application, the procedure ends and is finished unsuccessfully. 



14.2.5 PIN unblocking 

The execution of the PIN unblocking procedure is independent of the corresponding PIN status, i.e. being blocked or 
not. 

The Terminal checks the UNBLOCK PIN status. If the UNBLOCK PIN status is "blocked", the procedure ends and is 
finished unsuccessfully. 

If the UNBLOCK PIN status is not "blocked", the Terminal uses the UNBLOCK PIN function. If the UNBLOCK PIN 
presented by the Terminal is equal to the corresponding UNBLOCK PIN of the application, the relevant PIN status 
becomes "unblocked" and the procedure is finished successfully. If the UNBLOCK PIN presented by the Terminal is 
not equal to the corresponding UNBLOCK PIN of the application, the procedure ends and is finished unsuccessfully. 

14.3 Application selection procedures 

1 4.3. 1 Application selection by use of the EFqir file 

Application selection by use of the EFqir file is the procedure where the Terminal reads the content of the EFqir file and 
presents the list of applications to the user whom can then make select one or more applications to activate. 

The Terminal performs the read procedure with EFdir and presents the applications that it supports to the user who may 
make a selection. If only one supported application is found this may be implicitly selected. 

14.3.2 Direct application selection 

An application may be selected, without reading the content of the EFqir file, by performing the SELECT procedure 
with the AID of the application to be selected. 

14.3.3 Direct application selection with partial AID 

This is ffs. 

14.4 General application related procedures 
14.4.1 Application session activation 

The Terminal performs the SELECT function with the AID of the selected application as a parameter. 



£75/ 



3G TS 31.101 version 3.2.0 Release 1999 93 ETSI TS 131 101 V3.2.0 (2000-07) 

If the SELECT function ends successfully the selected application's initialisation procedure is executed. If the 
initialisation procedure ends successfully the UICC enters the operation state. If the initialisation procedure does not 
end successfully, the UICC remains in the application management state and sends an indication to the user that it was 
not possible to activate the selected application. 

14.4.2 UICC Application interrogation 

The list of applications residing in the UICC can be read at anytime when the UICC is not inactive. 
Request: The Terminal performs the read procedure with EFdir. 

14.4.3 UICC application session termination 

An application session can be terminated at any time when the UICC is not inactive. 

14.5 Miscellaneous procedures 

14.5.1 UICC activation 

After activation of the UICC, as defined in subclause 4.5, the Terminal requests the Preferred Language (EFpl). If the 
terminal supports USAT, it shall perform the USAT initialization procedure. The Terminal then performs an application 
selection procedure according to subclause 14.3. 

14.5.2 UICC presence detection 

To ensure that the UICC has not been removed during a card session, the Terminal sends, at frequent intervals, a 
STATUS command during each call. A STATUS command shall be issued within all 30 second periods of inactivity on 
the UICC-Terminal interface during a call. Inactivity in this case is defined as starting at the end of the last 
communication or the last issued STATUS command. If no response data is received to this STATUS command, then 
the call shall be terminated as soon as possible but at least within 5 seconds after the STATUS command has been sent. 
If the DP indicated in response to a STATUS command is not the same as that which was indicated in the previous 
response, or accessed by the previous command, then the call shall be terminated as soon as possible but at least within 
5 seconds after the response data has been received. This procedure shall be used in addition to a mechanical or other 
device used to detect the removal of a UICC. 

14.5.3 UICC Preferred Language request 

Request: The Terminal performs the read procedure with EFpL. 

Update: The Terminal performs the update procedure with EFpL. 

14.6 USAT related procedures 

The higher level procedures, and contents and coding of the commands, are given in TS 31.111 [4]. Procedures relating 
to the transmission of commands and responses across the Terminal-UICC interface are given in this section. A UICC 
or Terminal supporting USAT shall conform to the requirements given in this section. 

14.6.1 USAT Initialization procedure 

A UICC shall support the USAT initialization procedure. A Terminal supporting USAT shall send the TERMINAL 
PROFILE C-APDU. The Terminal shall then start the proactive polling procedure with the default value. 



14.6.2 Proactive polling 



During idle mode the Terminal shall send STATUS commands to the UICC at intervals no longer than the interval 
negotiated with the UICC (see TS 3 LI 1 1 [4]). During a call the UICC presence detection applies. The default value for 
the proactive polling is the same as for the presence detection procedure. 
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1 4.6.3 Support of commands 

A Terminal supporting USAT shall support the commands TERMINAL PROFILE, ENVELOPE, FETCH and 
TERMINAL RESPONSE. 

1 4.6.4 Support of response codes 

A Terminal supporting USAT shall support the response status words (SWl SW2) '91 XX' and '93 00'. 
These responses shall never be used if the Terminal does not support USAT. 

1 4.6.5 Independence of applications and USAT tasks 

Application and USAT operation shall be logically independent, both in the UICC and in the Terminal. Specifically, 
this means: 

The currently selected EF and current record pointer in any active application shall remain unchanged, if still 
valid, as seen by the Terminal, irrespective of any USAT activity. 

Between successive USAT related command-response pairs, other application (e.g. USIM) and UICC related 
command-response pairs can occur. The USAT task status shall remain unchanged by these command-response 
pairs. 

1 4.6.6 Use of BUSY status response 

If for any reason the USAT task of the UICC cannot process an ENVELOPE command issued by the Terminal at 
present (e.g. other USAT processes are already running), the UICC can respond with a status response of '93 00'. The 
Terminal may re-issue the command at a later stage. 

The BUSY status response has no impact on USIM operation. 

14.6.7 Additional processing time 

The Transport Protocol provides a mechanism for the UICC to obtain additional processing time (i.e. NULL procedure 
byte for T=0 and Work Waiting time extension (WTX) for T=l) before supplying the response part of a 
command-response pair, during which time the Terminal is unable to send further commands to the UICC. 

If a USAT activity in the UICC runs for too long, this may prevent the Terminal from sending USIM commands which 
are time-critical, e.g. INTERNAL AUTHENTICATE. A MORE TIME command is defined in TS 31.111 [4], which 
ensures that the USAT task in the UICC gets additional processing time, while at the same time freeing the 
UICC/Terminal interface. The MORE TIME command should be used in preference to the Transport Protocol specific 
mechanisms for optaining additional processing time. 
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Annex A (normative): 

UCS2 Coding of Alpha fields for files residing on the UICC 

If 16 bit UCS2 characters as defined in ISO/IEC 10646 [18] are used in an alpha field, the coding can take one of three 
forms. If the Terminal supports UCS2 coding of alpha fields in the UICC, the Terminal shall support all three coding 
schemes for character sets containing 128 characters or less; for character sets containing more than 128 characters, the 
Terminal shall at least support the first coding scheme. If the alpha field record contains GSM default alphabet 
characters only, then none of these schemes shall be used in that record. Within a record, only one coding scheme, 
either the GSM default alphabet (see 3G TS 23.038 [1]), or one of the three described below, shall be used. 



1) 



2) 



If the first byte in the alpha string is '80', then the remaining bytes are 16 bit UCS2 characters, with the more 
significant byte (MSB) of the UCS2 character coded in the lower numbered byte of the alpha field, and the less 
significant byte (LSB) of the UCS2 character is coded in the higher numbered alpha field byte, i.e. byte 2 of the 
alpha field contains the more significant byte (MSB) of the first UCS2 character, and byte 3 of the alpha field 
contains the less significant byte (LSB) of the first UCS2 character (as shown below). Unused bytes shall be set 
to 'FF', and if the alpha field is an even number of bytes in length, then the last (unusable) byte shall be set to 
'FF'. 

Example 1 



Byte1 


Byte 2 


Bytes 


Byte 4 


Byte 5 


Byte 6 


Byte? 


Byte 8 


Byte 9 


'80' 


ChlMSB 


ChlLSB 


Ch2MSB 


Ch2LSB 


ChSMSB 


ChStsB 


'FF' 


'FF' 



If the first byte of the alpha string is set to '81', then the second byte contains a value indicating the number of 
characters in the string, and the third byte contains an 8 bit number which defines bits 15 to 8 of a 16 bit base 
pointer, where bit 16 is set to zero, and bits 7 to 1 are also set to zero. These sixteen bits constitute a base pointer 
to a "half -page" in the UCS2 code space, to be used with some or all of the remaining bytes in the string. The 
fourth and subsequent bytes in the string contain codings as follows; if bit 8 of the byte is set to zero, the 
remaining 7 bits of the byte contain a GSM Default Alphabet character, whereas if bit 8 of the byte is set to one, 
then the remaining seven bits are an offset value added to the 16 bit base pointer defined earlier, and the resultant 
16 bit value is a UCS2 code point, and completely defines a UCS2 character. 

Example 2 



Bytel 


Byte 2 


Byte 3 


Byte 4 


Byte 5 


Byte 6 


Byte? 


Byte 8 


Byte 9 


'81' 


'05' 


'13' 


'53' 


'95' 


'A6' 


'XX' 


'FF' 


'FF' 



In the above example: 

- byte 2 indicates that there are 5 characters in the string; 

- byte 3 indicates bits 15 to 8 of the base pointer, and indicates a bit pattern of Ohhh hhhh hOOO 0000 as the 16 
bit base pointer number. Bengali characters for example start at code position 0980 (0 000 1001 7 000 0000), 
which is indicated by the coding '13' in byte 3 (shown by the italicised digits); 

- byte 4 indicates GSM Default Alphabet character '53', i.e. "S"; 

- byte 5 indicates a UCS2 character offset to the base pointer of '15', expressed in binary as follows 001 0101, 
which, when added to the base pointer value results in a sixteen bit value of 000 1001 1 001 0101, i.e. '0995'. 
which is the Bengali letter KA; 

- byte 8 contains the value 'FF', but as the string length is 5, this a valid character in the string, where the bit 
pattern 111 1111 is added to the base pointer, yielding a sixteen bit value of 0000 1001 1111 1111 for the 
UCS2 character (i.e. '09FF'). 
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3) If the first byte of the alpha string is set to '82', then the second byte contains a value indicating the number of 

characters in the string, and the third and fourth bytes contain a 16 bit number which defines the complete 16 bit 
base pointer to a "half -page" in the UCS2 code space, for use with some or all of the remaining bytes in the 
string. The fifth and subsequent bytes in the string contain codings as follows; if bit 8 of the byte is set to zero, 
the remaining 7 bits of the byte contain a GSM Default Alphabet character, whereas if bit 8 of the byte is set to 
one, the remaining seven bits are an offset value added to the base pointer defined in bytes three and four, and 
the resultant 16 bit value is a UCS2 code point, and defines a UCS2 character. 

Example 3 



Bytel 


Byte 2 


Byte 3 


Byte 4 


Byte 5 


Byte 6 


Byte? 


Byte 8 


Byte 9 


'82' 


'05' 


'05' 


'30' 


'2D' 


'82' 


'D3' 


'2D' 


'31' 



In the above example: 

- byte 2 indicates that there are 5 characters in the string; 

- bytes 3 and 4 contain a sixteen bit base pointer number of '0530', pointing to the first character of the 
Armenian character set; 

- byte 5 contains a GSM Default Alphabet character of '2D', which is a dash "-"; 

- byte 6 contains a value '82', which indicates it is an offset of '02' added to the base pointer, resulting in a 
UCS2 character code of '0532', which represents Armenian character Capital BEN; 

- byte 7 contains a value 'D3', an offset of '53', which when added to the base pointer results in a UCS2 code 
point of '0583', representing Armenian Character small PIWR. 
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Annex B (informative): 
Main states of a UICC 



A UICC complying to this standard has the following states of operation: 

"Inactive" - In this state the UICC is powered off. 

"Application management" - In this state it is possible to start/end one or more application-session(s) as well as 
retrieve the list of applications in the UICC. This state can be entered at any time when the UICC is not in the 
inactive state and left when the PIN access condition for all the selected applications has been verified. 

"Operation" - This state is entered after the application session activation procedure for at least one application 
has ended successfully. 



Activate 




De-activate 



Appl_sel_req 



Figure B.I : UICC states 
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Annex C (informative): 

APDU Protocol Transmission Examples 

C.1 Exchanges Using T=0 

The following examples illustrate exchanges of data and procedure bytes between the terminal and the UICC. 
Note the following: 

The use of procedure bytes '60' and I N S is not illustrated. 

[Data(X)] means X bytes of data. 

Case 2 and 4 commands may have Le = '00' requesting the return of all data from the UICC up to the maximum 
available. 

The examples in clauses C. 1.1.1 to C. 1.1. 4 illustrate typical exchanges using case 1 to 4 commands. The examples in 
the subclauses C.1.1.5 and C.1.1.6 illustrate the more extensive use of procedure bytes '61 XX' when used with case 2 
and 4 commands. The example in subclause C.1.1.7 illustrates a warning condition with a case 4 command. 

C.1.1 Case 1 Command 

A C-APDU of {CLA INS PI P2} is passed from the Terminal to the UICC (note that P3 of the C-TPDU is set to '00'). 

Terminal UICC 

C-TPDU [CLAINSPl P2P3=00] ^ 

<= 90 00 

An R-APDU of {90 00} is returned from the UICC to the Terminal. 

C.1.2 Case 2 Command 

In this example, a C-APDU of {CLA INS PI P2 Le=00} is passed from the Terminal to the UICC. 

Terminal UICC 

C-TPDU [CLAINSP1P2P3=00] ^ 

.^ 6C Luicc 

C-TPDU [CLA INS PI P2 Luicc] ^ 

<^ INS [Data(Luicc)] 90 00 

An R-APDU of { [Data(Luicc)] 90 00} is returned from the UICC to the Terminal. 
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C.1.3 Case 3 Command 



A C-APDU of {CLA INS PI P2 Lc [Data(Lc)] } is passed from the Terminal to the UICC. 

Terminal UICC 



[INS] 
90 00 



C-TPDU [CLA INS PI P2 P3=Lc] ^ 

<= 
[Data(Lc)] =^ 

<= 
An R-APDU of {90 00} is returned from the UICC to the Terminal. 

C.1.4 Case 4 Command 

A C-APDU of {CLA INS PI P2 Lc [Data (Lc)] Le=00} is passed from the Terminal to the UICC. 

Terminal UICC 



C-TPDU [CLA INS PI P2 P3=Lc] 

[Data(Lc)] 
GET RESPONSE [00 CO 00 00 Luicc] 



[INS] 

61 Luicc 

CO [Data(Luicc)] 90 00 



An R-APDU of { [Data(Luicc)] 90 00} is returned from the UICC to the Terminal. 

C.1 .5 Case 2 Commands Using the '61 ' and '6C' Procedure Bytes 



A C-APDU of {CLA INS PI P2 Le=00} is passed from the Terminal to the UICC. 

Terminal 

C-TPDU [CLA INS PI P2 P3=00] ^ 

<= 
[CLA INS PI P2 Luicc] ^ 

<= 
GET RESPONSE [00 CO 00 00 YY] ^ 

<= 
[00 CO 00 00 ZZ] ^ 



UICC 

6C Luicc 

61 XX 

CO [Data(YY)] 61 ZZ 

CO [Data(ZZ)] 90 00 



Where YY < XX. 

An R-APDU of { [Data(YY + ZZ)] 90 00} is returned from the UICC to the Terminal. 
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C.1 .6 Case 4 Command Using the '61 ' Procedure Byte 

A C-APDU of {CLA INS PI P2 Lc [Data Lc] Le=00} is passed from the Terminal to the UICC. 



C-TPDU 



GET RESPONSE 



Terminal 

[CLAINSPlP2P3=Lc] 

[Data(Lc)] 
[00 CO 00 00 XX] 
[00 CO 00 00 YY] 



UICC 

[INS] 

61 XX 
CO [Data(XX)] 61 YY 
CO [Data(YY)] 90 00 



An R-APDU of {[Data(XX + YY)] 90 00} is returned from the UICC to the Terminal. 

C.1 .7 Case 4 Command with Warning Condition 

A C-APDU of {CLA INS PI P2 Lc [Data Lc] Le=00} is passed from the Terminal to the UICC. 



C-TPDU 



GET RESPONSE 



Terminal 

[CLAINSPlP2P3=Lc] 

[Data(Lc)] 

[00 CO 00 00 00] 

[00 CO 00 00 Luicc] 



UICC 



[INS] 

62 XX 

6C Luicc 

CO [Data(Luicc)] 90 00 



An R-APDU of { [Data(Luicc)] 62 XX} is returned from the Terminal to the UICC containing the data returned together 
with the warning status bytes. 
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Annex D (informative): 
ATR Examples 

This annex gives examples of ATRs that can be returned by a UICC after a reset. 
1) Example 1: Cold reset for a T=0 protocol only UICC. 



Character 


Value 


Description 


TS 


'3B' or 'SF 


Indicates direct or inverse convention 


TO 


'97' 


TA1 and TD1 are present 
7 bytes of historical bytes 


TA1 


'95' 


Clock rate conversion factor Fl=9 (F=512) 
Baud rate adjustment factor Dl=5 (D=16) 


TD1 


'80' 


TD2 only is present 


TD2 


'IF 


TA3 only is present 

Global interface bytes following 


TA3 


'42' 


Clock stop supported (low electrical state) 
3V UICC 


T1 


'80' 




T2 


'31' 


Card data services 


T3 


'CO' 


SELECT by AID supported 
EFDIR present 


T4 


'73' 


Card capabilities 


T5 


'BE' 


SFI supported 


T6 


'20' 




T7 


'00' 


No extended Lc and Le 

No Logical cfiannels supported 


TCK 


'XX' 


Cfieck byte 



2) Example 2: Cold reset for a T=0 and T=l protocol UICC. 



Character 


Value 


Description 


TS 


'3B' or '3F 


Indicates direct or inverse convention 


TO 


'97' 


TA1 , and TD1 are present 
7 bytes of historical bytes 


TA1 


'95' 


Clock rate conversion factor Fl=9 (F=512) 
Baud rate adjustment factor Dl=5 (D=16) 


TD1 


'80' 


Only TD2 is present 

Protocol T=0 supported by UICC 


TD2 


'B1' 


TA3, TB3 and TD3 are present 
Protocol T=1 supported by UICC 


TA3 


'FE' 


IFSC is 254 bytes long 


TB3 


'00' 


Block Waiting lnteger=0 
Character Waiting lnteger=0 


TD3 


'IF 


Only TA4 is present 

Global interface bytes following 


TA4 


'42' 


Clock stop supported (low electrical state) 
3V UICC 


T1 


'80' 




T2 


'31' 


Card data services 


T3 


'CO' 


SELECT by AID supported 
EFDIR present 


T4 


'73' 


Card capabilities 


T5 


'BE' 


SFI supported 


T6 


'20' 




T7 


'00' 


No extended Lc and Le 

No Logical channels supported 


TCK 


'XX' 


Check byte 



3) Example 3: Warm reset (specific mode) and T=l protocol requested by UICC. 
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Character 


Value 


Description 


TS 


'3B' or '3F 


Indicates direct or inverse convention 


TO 


'97' 


TA1 , and TD1 are present 
7 bytes of historical bytes 


TA1 


'95' 


Clock rate conversion factor Fl=9 (F=512) 
Baud rate adjustment factor Dl=5 (D=16) 


TD1 


'91' 


TA2 and TD2 are present 
Protocol T=1 supported by UICC 


TA2 


'81' 


Protocol T=1 used in specific mode 

Parameters indicated by the interface bytes, and card is 

enable to change mode 


TD2 


'81' 


TA3, TB3 and TD3 are present 
Protocol T=1 supported by UICC 


TA3 


'FE' 


IFSC is 254 bytes long 


TBS 


'00' 


Block Waiting lnteger=0 
Character Waiting lnteger=0 


TD3 


'OF 


Global interface bytes following (none so use previous ones) 


T1 


'80' 




T2 


'31' 


Card data services 


T3 


'CO' 


SELECT by AID supported 
EFdir present 


T4 


'73' 


Card capabilities 


T5 


'BE' 


SFI supported 


T6 


'20' 




T7 


'00' 


No extended Lc and Le 

No Logical channels supported 


TCK 


'XX' 


Check byte 
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Annex E (informative): 

Security Attributes IVIechanisms and Examples 

E.1 Coding 

Two codings are defined: 

a compact coding based on bitmaps; 

an expanded coding which is an extension of the compact coding with intermediate scope containing bitmap and 
TLV Hst management. 

The security conditions for bits not set to '1' in the AM byte are set to NEVer by defauh. 

E.2 Compact format 

The compact format access rule is indicated by tag '8C' in the FCP. An access rule in this format is encoded with: 

- an AM byte as defined in ISO/IEC 7816-9 [17]; 

- one or more SC bytes as defined in ISO/IEC 7816-9 [17]. 

E.2.1 AlVI byte 

The AM byte conveys two types of information: 

interpretation of the AM byte itself; 

number of SC bytes in the access rule. 

If b8 in the AM byte is set to '0' the AM byte is followed by a number of SC bytes equal to the number of bits set to '1' 
in the AM byte (excluding b8). Each SC bytes codes the conditions relevant to a set of commands, in the same order (b7 
to bl) as in the AM byte. When b8 is set to '1' the usage of b7-b4 is proprietary. 

When multiple sets of an AM byte and one or more corresponding SC bytes are present in the value field of the DO, tag 
'8C' they represent an OR condition. 



E.2.2 SC byte 



The SC byte specifies which security mechanisms are necessary to conform to the access rules, see ISO/IEC 7816-9 
[17]. The 4 most significant bits (b8-b5) indicate the required security condition. An SE may be specified in bits b4— bl. 
If an SE is specified, the mechanisms that may be defined in it for external authentication, user authentication and 
command protection shall be used, if indicated by bits b4-bl. 

If bit b8 is set to '1' all conditions in bits b7-b5 shall be satisfied. If bit b8 is set to '0' at least one of the conditions set in 
bits b7-b5 shall be satisfied. If b7 is set to '1', the CRT of the SE indicated in bits b4-bl describes whether secure 
messaging shall apply to the command APDU, the response APDU or both. 

E.2.3 Examples 

For EFs with the access condition ALW for READ and UPDATE the security attribute would look as follows: 
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Tag 


L 


AM 


sc 


sc 


'8C' 


'03' 


'03' 


'00' 


'00' 



For EFs with the access condition ALW for READ and NEV for all other access conditions the security attribute would 
look as follows: 



Tag 


L 


AM 


SC 


'8C' 


'02' 


'01' 


'00' 



For EFdir and EF icc the access rule would be as follows. READ is set to always UPDATE, DEACTIVATE and 
ACTIVATE is set to ADM. The ADM condition is indicated as a user authentication. The key reference is implicitly 
known. 



Tag 


L 


AM 


SC 


SC 


SC 


SC 


'8C' 


'05' 


'1B' 


'90' 


'90 


'90' 


'00' 



E.3 Expanded format 



In the expanded format AM_DOs and SC_DOs are used to create the access rules. The expanded format access rule is 
indicated by tag 'AB' in the FCI. An access rule in this format is encoded with an AM_DO followed by a sequence of 
SC_DOs. 

E.3.1 AM_DO 

The AM_DO is defined in ISO/IEC 7816-9 [17]. The content of the AM_DO is defined by the tag value. Tag '80' 
indicates that the AM_DO contains an AM byte. Tags '81'-'8F' indicates that the AM_DO contains a command 
description. The content of the command description is dependent upon the tag value as defined in 
ISO/IEC 7816-9 [17]. Tag '9C' indicates that the AM_DO contains a proprietary state machine description. 

When multiple sets of an AM_DO and one or more corresponding SC_DOs are present in the value field of the DO, tag 
'AB', they represent an OR condition. 

E.3.2 SC_DO 

The SC_DO is defined in ISO/IEC 7816-9 [17]. The SC_DO definition contains an OR and an AND template. Several 
SC_DOs may be attached to a particular operation. 

if the SC_DOs are encapsulated in an OR template, then only one of the security conditions has to be fulfilled for 
the operation to be allowed; 

if the SC_DOs are not to be encapsulated in an OR template or if the SC_DOs are encapsulated in an AND 
template, then all security conditions shall be fulfilled before the operation is allowed. 



E.3.3 Access rule referencing 



Access rules in expanded format (AM_DOs and SC_DOs) may be stored in a linear fixed/variable EF, each record 
contain one or more rules, as defined in ISO/IEC 7816-9 [17]. The access rule file may be an internal file, referenced 
implicitly, or may be referenced explicitly, e.g. by a file ID. The access rule stored in a file is indicated by tag '8B' in the 
FCI. The value of this DO contains at least one record number, called ARR. The DO can contain: 

a single byte containing the record number of the rule, valid if the access rule file is (implicitly) known; 

three bytes containing two bytes with the File ID of the access rule file followed by one byte with the record 
number for the access rule; 
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if the value filed is coded with a length of 2+nx2, for n>l, it contains one or more SEID/ARR pairs, where the 
SEID codes the SE number on one byte. For each SE number, the access rules indicated in the ARR following its 
SE number are valid. 



E.3.4 Examples 



The access rule for EFpL would look as follows. The READ and SEARCH access condition is ALWays. The UPDATE 
access condition is Application! PIN or Application2 PIN. 







Ol 














=? 
















Ol 












O) 














a 














." 
















."■ 


























1- 










H 




1- 






Q> 0) 






H 




H 






0) a> 






1- 






1- 






-1 


O 

a 
< 


-1 


> 


o 


-1 


o 

Q 

1 

O 

to 


-1 


> 


-1 


> 


=1 


-1 
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DC 

5 


-1 


> 


ra — 

= 1 


-1 


> 


O 

Q 
1 

< 


-1 


> 


o 

o 

o' 


-1 


'AB' 


'1A' 


'80' 


'01' 


'02' 


'AO' 


'10' 


'A4' 


'06' 


'83' 


'01' 


'01 


'95' 


'01' 


'08' 


'A4' 


'06' 


'83' 


'01' 


'02' 


'95' 


'01' 


'08' 


'80' 


'01' 


'01' 


'90' 


'00' 
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Annex F (Informative): 

Example of contents of EFarr '2F06' 

F.1 Sample content of the EFarr 

This annex contains an example of the contents of EFarr '2F06'. 

Table F.1.1 : Access Rule References for files located at the MF level 



ARR 


Appli 


Access 


AlVI 


LEN 


Value 


SCDO: 


Security 


Len 




Value 






Record 


cable 


Condition 


DO 






CRT 
Tag 


Condition 














Key 


Len 


Value 


Usage 


Len 


Value 




















Ref 






Qualifier 
























Tag 






Tag 






01 


EF 


READ 


'80' 


'01' 


'01' 


'90' 


ALW 


'00' 


















UPDATE/ 


'80' 


'01' 


'1A" 


'A4' 


Level 5 


'06' 


'83' 


'01' 


'OX' 


'95' 


'01' 


'YY' 






DE-ACTIVATE/ 






























ACTIVATE 


























02 


EF 


READ 


'80' 


'01' 


'01' 


'90' 


ALW 


'00' 


















UPDATE/ 


'80' 


'01' 


'18" 


'A4' 


Level 5 


'06' 


'83' 


'01' 


'OX' 


'95' 


'01' 


'YY' 






DEACTIVATE/A 






























CTIVATE 


























03 


EF 


READ 


'80' 


'01' 


'01' 


'90' 


ALW 


'06' 


'83' 


'01' 


'01' 


'95' 


'01' 


'01' 






UPDATE/ 


'80' 


'01' 


'1A" 


'A4' 


Level 5 


'06' 


'83' 


'01' 


'OX' 


'95' 


'01' 


'YY' 






DEACTIVATE/A 






























CTIVATE 



























The value X in table F.1.1 shall be according to level 5 in table 9.3. The value 'YY' in table F.1.1 shall be in accordance 
with ISO/IEC 7816-9 [17]. 
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Annex G (informative): 

Access Rules Referencing (ARR) 

G.1 Sample content of EFarr 

This annex contains a set of access rule examples that are stored in EFarr. The access rules are referenced using tag'SB' 
in the FCP. 

The following definitions apply: 

the application PIN is referred to as PIN Appl. 1 global (key reference '01'); 

- the UICC supports the usage of a universal PIN, see subclause 9.4.1, that is referred to as UNIVERSAL PIN 
(key reference '11'); 

the application PIN2 is referred to as Second PIN Appl.l local (key reference '81'); 

access condition ADM is referenced as Level 5/Level 6 (key reference 'YZ') where: 

- 'Y' = '0' for Level 5 and 'Y' = '8' for Level 6; 

'Z' = 'A' to 'E' for Levels and Level 6; 

the value 'XX' for the usage qualifier for key reference value 'YZ' is according to ISO/IEC 7816-9 [17]. 
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Table G1.1 : Application Access Rule References 



ARR 
Record 


Applic 
able 


Access 
Condition 


AM DO 


LEN 


Value 


SCDO: 
CRT Tag 


Security 
Condition 


Len 


Value 


Key 
Ret 
Taq 


Len 


Value 


Usage 

Qualifier 

Tag 


Len 


Value 


01 


EF 


READ 


'80' 


'01' 


'01' 


'90' 


ALW 


'00' 














02 


EF 


READ 
UPDATE 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 
'80' 


'01' 
'01' 
'01' 


'01' 
'02' 
'18' 


'90' 
'A4' 
'A4' 


ALW 

PIN AppI 1 global 

Level 5/Level 6 


'00' 
'06' 
'06' 


'83' 
'83' 


'01' 
'01' 


'01' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX' 


03 


EF 


READ 
UPDATE/ 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 


'01' 
'01' 


'01' 
'1A" 


'A4' 
'A4' 


PIN App1 1 global 
Level 5/Level 6 


'06' 
'06' 


'83' 
'83' 


'01' 
'01' 


'01' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX 


04 


EF 


READ/UPDATE 

DEACTIVATE/ 

ACTIVATE 


'80' 
'80' 


'01' 
'01' 


'03' 
'18' 


'A4' 
'A4' 


PIN App1 1 global 
Level 5/Level 6 


'06' 
'06' 


'83' 
'83' 


'01' 
'01' 


'01' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX 


05 


EF 


READ 
UPDATE 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 
'80' 


'01' 
'01' 
'01' 


'01' 
'02' 
'18' 


'A4' 
'A4' 
'A4' 


PIN App1 1 global 
PIN2 App1 1 local 
Level 5/Level 6 


'00' 
'06' 
'06' 


'83' 
'83' 
'83' 


'01' 
'01' 
'01' 


'01' 
'81' 
'YZ' 


'95' 
'95' 
'95' 


'01' 
'01' 
'01' 


'08' 
'08' 
'XX 


06 


EF 


READ 
UPDATE/ 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 


'01' 
'01' 


'01' 
'1A" 


'90' 
'A4' 


ALW 

Level 5/Level 6 


'00' 
'06' 


'83' 


'01' 


'YZ' 


'95' 


'01' 


'XX 


07 


EF 


READ/UPDATE/ 

ACTIVATE 

DEACTIVATE 


'80' 
'80' 


'01' 
'01' 


'13' 
'08' 


'A4' 
'A4' 


PIN App1 1 global 
Level 5/Level 6 


'06' 
'06' 


'83' 

'83' 


'01' 
'01' 


'01' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX 


08 


EF 


READ/UPDATE/ 

ACTIVATE/ 

DEACTIVATE 


'80' 


'01' 


'IB' 


'A4' 


Level 5/Level 6 


'06' 


'83' 


'01' 


'YZ' 


'95' 


'01' 


'XX 


09 


EF 


READ/UPDATE 
DEACTIVATE/ 
ACTIVATE 
INCREASE 


'80' 
'80' 

'84' 


'01' 
'01' 

'01' 


'03' 
'18' 

'32' 


'A4' 
'A4' 

'A4' 


PIN App1 1 global 
Level 5/Level 6 

PIN App1 1 global 


'06' 
'06' 

'06' 


'83' 
'83' 

'83' 


'01' 
'01' 

'01' 


'01' 
'YZ' 

'01' 


'95' 
'95' 

'95' 


'01' 
'01' 

'01' 


'08' 
'XX 

'08' 


10 


EF 


READ/UPDATE 
DEACTIVATE/ 
ACTIVATE 
INCREASE 


'80' 
'80' 

'84' 


'01' 
'01' 

'01' 


'03' 
'18' 

'32' 


'A4' 
'A4' 

'A4' 


PIN App1 1 global 
Level 5/Level 6 

PIN2 App1 1 global 


'06' 
'06' 

'06' 


'83' 
'83' 

'83' 


'01' 
'01' 

'01' 


'01' 
'YZ' 

'81' 


'95' 
'95' 

'95' 


'01' 
'01' 

'01' 


'08' 
'XX 

'08' 


11 


EF 


READ 
UPDATE 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 
'80' 


'01' 
'01' 
'01' 


'01' 
'02' 
'18' 


'90' 
'A4' 
'A4' 


ALW 

Universal PIN 
Level 5/Level 6 


'00' 
'06' 
'06' 


'83' 
'83' 


'01' 
'01' 


'11' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX 


12 


EF 


READ 
UPDATE/ 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 


'01' 
'01' 


'01' 
'1A" 


'A4' 
'A4' 


Universal PIN 
Level 5/Level 6 


'06' 
'06' 


'83' 
'83' 


'01' 
'01' 


'11' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX 


13 


EF 


READ/UPDATE 
DEACTIVATE/A 
CTIVATE 


'80' 
'80' 


'01' 
'01' 


'03' 
'18' 


'A4' 
'A4' 


Universal PIN 
Level 5/Level 6 


'06' 
'06' 


'83' 
'83' 


'01' 
'01' 


'11' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX 


14 


EF 


READ 
UPDATE 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 
'80' 


'01' 
'01' 
'01' 


'01' 
'02' 
'18' 


'A4' 
'A4' 
'A4' 


Universal PIN 
PIN2 App1 1 local 
Level 5/Level 6 


'00' 
'06' 
'06' 


'83' 
'83' 
'83' 


'01' 
'01' 
'01' 


'11' 
'81' 
'YZ' 


'95' 
'95' 
'95' 


'01' 
'01' 
'01' 


'08' 
'08' 
'XX 


15 


EF 


READ 
UPDATE/ 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 


'01' 
'01' 


'01' 
'1A" 


'90' 
'A4' 


ALW 

Level 5/Level 6 


'00' 
'06' 


'83' 


'01' 


'YZ' 


'95' 


'01' 


'XX 


16 


EF 


READ/UPDATE/ 

ACTIVATE 

DEACTIVATE 


'80' 
'80' 


'01' 
'01' 


'13' 
'08' 


'A4' 
'A4' 


Universal PIN 
Level 5/Level 6 


'06' 
'06' 


'83' 
'83' 


'01' 
'01' 


'11' 
'YZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX 


17 


EF 


READ/UPDATE/ 

ACTIVATE/ 

DEACTIVATE 


'80' 


'01' 


'IB' 


'A4' 


Level 5/Level 6 


'06' 


'83' 


'01' 


'YZ' 


'95' 


'01' 


'XX 


18 


EF 


READ/UPDATE 
DEACTIVATE/ 
ACTIVATE 
INCREASE 


'80' 
'80' 

'84' 


'01' 
'01' 

'01' 


'03' 
'18' 

'32' 


'A4' 
'A4' 

'A4' 


Universal PIN 
Level 5/Level 6 

Universal PIN 


'06' 
'06' 

'06' 


'83' 
'83' 

'83' 


'01' 
'01' 

'01' 


'11' 
'YZ' 

'11' 


'95' 
'95' 

'95' 


'01' 
'01' 

'01' 


'08' 
'XX 

'08' 


19 


EF 


READ/UPDATE 
DEACTIVATE/ 
ACTIVATE 
INCREASE 


'80' 
'80' 

'84' 


'01' 
'01' 

'01' 


'03' 
'18' 

'32' 


'A4' 
'A4' 

'A4' 


Universal PIN 
Level 5/Level 6 

PIN2 App1 1 global 


'06' 
'06' 

'06' 


'83' 
'83' 

'83' 


'01' 
'01' 

'01' 


'11' 
'YZ' 

'81' 


'95' 
'95' 

'95' 


'01' 
'01' 

'01' 


'08' 
'XX 

'08' 
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Table G.I .2: DpTeiecom Access Rule References 



ARR 
Record 


Applic 
able 


Access 
Condition 


AiVIDO 


L 


V 


SCDO 
CRT 
Tag 


Security Condition 


L 


SCDO 
CRT 
Tag 


L 


Vaiue 


SCDO 
CRT 
Tag 


L 


Vaiue 


Key 
Ret 
Tag 


L 


V 


Usage 

Quaiifier 

Tag 


L 


V 


Key 
Ret 
Tag 


L 


V 


Usage 

Quaiifier 

Tag 


L 


V 


01 


EF 


READ 


80' 


'01' 


or 


'90' 


ALW 


'00' 






- 


- 




- 




- 






- 




- 


- 


- 


- 


02 


EF 


READ 
UPDATE 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 
'80' 


'01' 
'01' 
'01' 


'01' 
'02' 
'18' 


'90' 
'AO' 
'A4' 


ALW 

PIN AppI 1 global OR PIN AppI 2 

Level 5 


'00' 
'10' 
'06' 


'A4' 


'06' 


'83' 
'83' 


'01' 
'01' 


'01' 
'OZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX' 


'A4' 


'06' 


'83' 


'01' 


'02' 


'95' 


'01' 


'08' 


03 


EF 


READ 
UPDATE/ 
DEACTIVATE/ 
ACTIVATE 


'80' 
'80' 


'01' 
'01' 


'01' 
'1A" 


'AO' 
'A4' 


PIN AppI 1 global OR PIN AppI 2 
Level 5 


'10' 
'06' 


'A4' 




'83' 
'83' 


'01' 
'01' 


'01' 
'OZ' 


'95' 
'95' 


'01' 
'01' 


'08' 
'XX' 


'A4' 


'06' 


'83' 


'01' 


'02' 


'95' 


'01' 


'08' 


04 


EF 


READ/UPDATE 

DEACTIVATE/ 

ACTIVATE 


'80' 
'80' 
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'01' 
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'OZ' 


'95' 
'95' 
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'01' 
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'XX' 


'A4' 
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'83' 


'01' 


'02' 
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'01' 
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05 


EF 
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'80' 
'80' 
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'01' 


'01' 
'1A" 


'90' 
'A4' 
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Level 5 


'00' 
'06' 






'83' 


'01' 


'OZ' 


'95' 


'01' 


'XX' 


















06 


EF 
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'80' 
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'01' 
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'A4' 
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'OZ' 
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'A4' 


'06' 
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'02' 


'95' 


'01' 
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07 


EF 
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'01' 


'OZ' 


'95' 


'01' 
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Annex H (informative): 
Change history 



The table below indicates all change requests that have been incorporated into the present document since it was 
initially approved by 3GPP TSG-T. 



Change history | 


Date 


Meeting 


TSG Doc. 


CR 


Rev 


Cat 


Subject/Comment 


Old 
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2000-04 


TP-07 


TP-000013 


001 


3 


B 


Security Attributes 


3.0.0 


3.1.0 


TP-000013 


002 


2 


B 


Incorporation of tlie USAT (USIM application toolkit) 
features. 


TP-000013 


003 


3 


B 


File Control Parameters 


TP-000013 


004 


1 


F 


Coding of status words 


TP-000013 


006 




B 


Definition of application session related procedures 


TP-000013 


007 




D 


Collection of 31 . 1 01 editorial changes 


TP-000013 


008 




C 


Power consumption 


TP-000013 


009 




F 


Changes to UICC specific files 


TP-000013 


010 




F 


Reservation of file IDs 


2000-07 


TP-08 


TP-000094 


Oil 




F 


Error detection and character repetition 


3.1.0 


3.2.0 


TP-000094 


012 




F 


Use of status codes 6200, 6400 and 6500 


TP-000094 


013 




F 


Correction of P2 value for the ACTIVATE and 
DEACTIVATE commands 


TP-000094 


014 




F 


Clarification of the UICC characteristics byte 


TP-000094 


015 




F 


Correction of ACTIVATE/DEACTIVATE commands 


TP-000094 


016 




F 


Clarification of the file descriptor 


TP-000094 


017 




F 


Selection by path correction 


TP-000094 


018 


1 


F 


Correction of ATR examples 


TP-000094 


019 




F 


SEARCH RECORD command: alignment with ISO/IEC 
7816-9 


TP-000094 


020 




F 


Correction to T=0 mechanism 


TP-000094 


022 




F 


Correction of the application activation termination 
procedures 
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